Recently I've had some time to spare, so I decided to refactor my Backlog Manager into a new version.

Here it is: Backlog Manager v10.1

It is more robust than the previous versions, and has better support for Release Planning.

Steve Berczuk has a lovely discussion of Manage Your Project Portfolio. You can see his review here.

Tweet This Post

It is perhaps a myth, but an enduring one, that people and their pets resemble one another. The same has been said of products and the teams that build them. If it is true that a product reflects the structure of the team that built it, then an important decision for any Scrum project is how to organize individuals into teams. This paper presents a set of guidelines to consider in designing an appropriate team structure. Each guideline is presented in the form of a question to be asked of a current or proposed team. The questions are intended to be asked iteratively. Ask each question of a current or proposed team, changing the structure as appropriate based on the answer. As the structure changes, re-ask the questions until you can answer “yes” to each.

1. Does the structure accentuate the strengths, shore up the weaknesses, and support the motivations of the team members? People don’t enjoy being on a team where they are not able to make use of their strengths or are constantly required to do things they are bad at. Good team members are willing to do whatever is necessary for the success of the project, but that doesn’t relieve us from the goal of trying to find a team structure that accentuates the strengths of as many team members as possible.
2. Does the structure minimize the number of people required to be on two teams (and avoid having anyone on three)? A well-conceived team structure for an organization that is not attempting to do too many concurrent projects will reduce multitasking to a tolerable level. If more than 20% of all team members belong to more than one team, consider an alternative team design or deferring some projects.
3. Does the structure maximize the amount of time that teams will remain together?
   If other factors are equal, you should favor a design that allows team membership to persist over a longer period. It takes time for individuals to learn to work well together. Amortize the cost of that learning over a longer period by trying to leave teams together as long as possible.
4. Are component teams used only in limited and easily justifiable cases? Most teams should be created around the end-to-end delivery of working features. In some cases, it is acceptable to have a component team developing reusable user interface components, providing access to a database, or similar functionality. But these should be exceptions.
5. Will you be able to feed most teams with two pizzas? Given the compelling productivity and quality advantages of small teams, the majority of teams in a good design should have five to nine members.
6. Does the structure minimize the number of communication paths between teams? A poor team structure design will result in a seemingly infinite number of communication paths between teams. Teams will find themselves unable to complete any work without coordinating first with too many other teams. Some inter-team coordination will always be required. But, if a team that wants to add a new field on a form is required to coordinate that effort with three other teams, as I’ve seen, then the communication overhead is too high.
7. Does the structure encourage teams to communicate who wouldn’t otherwise do so? Some teams will just naturally communicate with each other. An effective team design encourages communication among teams or individuals who should communicate but may not do so on their own accord. In fact, one valid reason to put someone on two teams is that doing so will increase the communication between those teams. If lack of communication between two teams is a concern, splitting a person’s time between those two teams is easily justified.
8. Does the design support a clear understanding of accountability? A well-designed team structure will reinforce the concept of a shared, all-teams accountability for the overall success of the project while providing each team with clear indicators of their unique accountabilities.
9. Did team members have input into the design of the team? During the early stages of your transition to Scrum, this may not be possible. Individuals may not yet have enough experience delivering working, tested, ready-to-use products by the end of each sprint. Similarly, some individuals may be initially too resistant to Scrum to contribute to team structure discussions in constructive ways. In these cases, it is acceptable for managers outside the team to design an initial team structure.

An effective team structure is one of the most critical factors in the success of any agile endeavor. Poorly structured teams will lead to inefficient teamwork, excessive integration challenges, multitasking, low morale and other problems. By using these nine questions to carefully consider how teams are organized you can avoid these problems.

Du hast Lust zu Reisen, ständig neue Teams kennen zu lernen, in einer weltweit bekannten Scrum Consulting Organisation State-of-the-Art-Scrum zu praktizieren und damit die Teams unserer Kunden erfolgreich zu machen?

Wir suchen dich, wenn du

• einen Hochschulabschluss in den Geisteswissenschaften oder Informatik hast,
• bis zwei Jahre Berufserfahrung hast, oder einen Doktor mitbringst,
• sehr gu Read more ...

Anders Storm, Head of Development and IT at Tekis AB, posted a cogent reminder of all that's good about Scrum (see Anders' post Why I Like Scrum! on his blog Product...

At times, wildly informative.

Heute begann das Scrum Gathering in Orlando, Florida. Den Anfang machte Jeff Sutherland mit Ken Johnson und sie sprachen über Scrum and CMMi. Eigentlich schade, dass wieder eine Keynote auf einem ScrumGathering für den Vergleich von Scrum mit CMMi genutzt wird. Andererseits hatte ich mal wieder Recht: Ich schreibe seit Jahren darüber, dass diese beiden Themen zusammen gehören.

Aber … ich glaube, dass das Scrum Gathering andere Read more ...

As nobody probably missed, my trust in Lotus Notes is below the freezing point. The quality is so low, the usability is a sad story and having used Outlook with Exchange, the lack of basic functionality in e-mail and calendar functionality amazes me. I shouldn’t be surprised anymore, but still….   Lotus Notes has two passwords, one for the Windows client and one for the web client. Today, I wanted to change the password for the web client. I looked in the horror story of Lotus Notes preferences and found nothing. Finally, I looked in the help section and I couldn’t believe my eyes. This is how you do it:  

To change your Internet password manually, enter the URL for a Web application and add “?changepassword” after the database name at the end of the URL. For example, http://serverName.acme.com/databasename.nsf?changepassword.

In the Change Password screen, enter your old Internet password, enter a new Internet password, and then confirm your new Internet password by entering it again in the corresponding fields. The password quality guidelines are the same as the Lotus Notes password guidelines.

Click Submit.

Are they crazy? I couldn’t find that you could change the settings using the Windows client, perhaps you can, but in that case the help section does not include the correct information which is really bad. But I don’t know if that is worse than leaving the suggested solution the only one for us poor Lotus Notes users.    

I'm currently evaluating the result of a project completed before I started working for TUI Nordic. I'm going through objectives documents, requirement lists, budgets, time schedules and business cases trying to find out if the project was a success or not.

Since many of the people have moved on to other projects, it almost feel like I'm doing historic research and that is perhaps a curse of the movern project culture within software development. A project is planned, born, lives but dies when it's completed. Completed projects are almost like old newspapers. They are so dead.

But when I entered this project graveyard, I found myself consumed by these numbers and ideas from the not so distant past. I dug into the numbers, crunching them, comparing, trying to find the answer to my question. I had to stop myself many times, drawing conclusions from incomplete data. Our minds are hard wired to draw conclusions and see patterns, even when there aren't any.

It is all to easy to just take two numbers and draw conclusions, make calculations, etc. In a way it's easier to make these calculations than not to.

So, is the project a success? Well, I've not completed my review but my response will probably be that it depends. It depends on who you ask and which aspect you look at. When we talk about successful projects, it's easy getting stuck in Time, Quality/Features and Cost. But what about learnings? There are always stuff which works less than well in a large project but if you don't see that and act on it so you avoid it in the next project, that must be the greatest failure of all.

It's probably easier just to stick to the numbers and lists, comparing and calculating. But who said one must always pick the easy road?

Jeff Sutherland at the Scrum Gathering in Orlando. What is the role of management in a Scrum environment:

• Have a business model that works 
• Ensure that the resources are present to achieve the business model 
• Eliminate impediments - this should get board level attention
• Challenge the teams 

 The role of "management" changes: it should become leadership.

We’ve added two new tools for prioritizing a product backlog: Theme Screening and Theme Scoring. Each of these is a lightweight way of comparing product backlog items to one another.

Theme Scoring

You can use theme scoring to compare user stories or entire projects against one another. In this technique you identify a set of criteria that will be important in prioritizing. Each item is assessed on a relative 1-5 scale against each criterion and the priorities are determined.

Theme Screening

Like theme scoring and relative weighting, this technique can be used to prioritize user stories or projects against one another. The simplest of the three prioritization techniques, theme screening starts with you identifying a baseline item. Each other item to be prioritized is compared to the baseline item for a set of factors that will determine priorities.

I spent the day yesterday with 30 of my CST and CSC colleagues in a session led by Mike Vizdos and Jean Tabaka exploring ways to improve our craft.  Mike had been very clear in his description of the session: it should be a positive experience — no complaints!  I’m happy to say we achieved that goal, and in a way that did not compromise of beliefs and values — and did not detract from the passion for Scrum, for “transforming the world of work” so rife in our group.

Sadly, my comments of two days ago “we are not very good” hung over a number of some members of our community (some present company, but mostly those not in attendance) as a negative force.  It is interesting, and maybe odd, how a phrase can be interpreted differently by different people.  Some found my words to be an attack, an insult while others saw the same phrase as a call to change, a challenge to improve.  It was also odd to me how it went from “you are not very good” to “you suck”.  On a 1-5 scale of very bad, bad, mediocre, good, very good I stated that we were not at position 5 (very good).  That is more likely to mean we are at the next level down (good) than off the scale altogether (at the wrong end) with “suck”.  I’m English, I don’t even use that word, but it seems worse than “very bad” to me.

Face-to-face, and one-to-one conversations go a long way towards better understanding. Why do you think we push so hard on having co-located teams?  Trust, respect and understanding are born through looking someone in the eye and speaking ones own truth.  I hope I mended some broken bridges yesterday.  The CST/CSC community is full of compassionate, passionate people who care deeply about what they do.  Maybe in the end that is a value of far greater worth than great training skills — and many of us have those too!  In fact, one of the things that really impressed me yesterday came from one of the newer trainers who simply stood up and said words to the effect of “I struggle with this, I feel underskilled and I need help”.  It is this desire to face our shortcomings and be willing to improve that sets the good trainer apart from the mediocre one.  Agile is all about continuous improvement. It has to start with the individual.

The highlight of the day for me was when Alan Cyment facilitated a lively, movement-and-discussion session to discover consensus on the meaning of the term “great CST”.  Alan’s style of facilitation is offbeat and exceptional: fast, physical, seemingly chaotic but always with clear and actionable output.  Alan rather conducts a group of people than facilitates them. It has to be experienced to be understood.

The session ended with a brilliantly funny exercise led by Jean Tabaka which consisted of drawing pictures based on written statements, and writing statements based on the subsequent picture.  After seven iterations of this, you can image the final statement had little to do with the original statement.  The output was hilarious.

So today we go into the conference proper, which kicks off with a keynote by Jeff Sutherland and is followed by eight deep-dive workshops run by Matt Smith, Lee Devin, Joseph Pelrine, Lyssa Adkins, Micah Martin, Karl Scotland, Luke Hohmann and Tom & Kai Gilb.  It promises to be a great day.

#SG10US | #SGUS10 | #SGUS

The day before the Scrum Gathering officially starts: I had a great talk with CSC Bob Hartman about Books, training techniques and the importance of values to a person or organization.

• Quoting from 'the Last Lecture': Tell the Truth. 
• To which Bob would add: All the Time. 
• And I would prepend: Live your values! 

Tell the Truth is about Honesty and Openness and is the basis for effective communication. All the time demands an atmosphere of Trust and Courage.

This for me is what Scrum is about. In my life, I have never gotten into trouble as long as I was staying close to my values. Lose sight of them, and bad news! IMHO, these are the problems that led to the fissure in the Scrum Alliance last fall, and also caused Toyota the problems that they are having now.

When I ask myself, what do I do as a coach? I teach people to apply these three principles:
Live your values. Tell the truth. All the time. And that they don't need to be afraid of doing so.

Read more ...

I'm happy to meet up!  Send my an email: clint [at] clintonkeith.com

In addition to the CSM4VG course I'm teaching, I have the following sessions:

Beyond Scrum: Agile Project Management for Games
Date/Time: Thursday (March 11, 2010)   9:00am — 10:00am
Location (room): Room 305, South Hall
Session Description
The session is not an introduction to Scrum. It describes how Scrum fits in to an entire game project management framework.

Agile: No Silver Bullet
Speaker: Chris Oltyan (Director of Product Development, ZeeGee Games), Rich Vogel (Co-Studio Director, BioWare), Clinton Keith (Clinton Keith Consulting), Michael Capps (President, Epic Games)
Date/Time: Friday (March 12, 2010)   9:00am — 10:00am
Location (room): Room 303, South Hall

Session Description
The goal of this panel is to discuss the good and the bad of agile development. Let's not sugar coat it, agile development is hard and does not fit all production paradigms. We'll discuss where the dogmatic approach to agile fails and where to apply practices from other areas, such as waterfall and lean. The panel will also answer audience questions directly and help diagnose how and why Agile projects went wrong, and methods teams and companies can use to get their processes back on track.

It should be a great GDC!

Join me at my new blog and website www.coachingagileteams.com. I am excited about the expanded content and offerings you will find there.  I hope you will be, too. Here are direct links to some specific places you may want to go: About Lyssa Training Dates In April, this blog will automatically redirect to CoachingAgileTeams.com.  [...]

Ein Kunde im Großraum Karlsruhe sucht

• Java Professionals
• Systemarchitekten
• BI Consultants
• und Linux Admins

in einem technologiegetriebenen Umfeld. Der Kunde ist ein IT-Beratungsunternehmen, beschäftigt sich mit der Entwicklung von individueller Business-Software (Java, Ruby und .NET), mit der Realisierung von Business-Intelligence-Systemen auf der Grundlage der Technologien von Microsoft Read more ...

In the late 1970s, in the Co-Evolution Quarterly, the magazine successor to The Whole Earth Catalog, Peter Warshall stated that geodesic dome houses always leak.  This was a bold and surprising statement at the time, coming from a man who was considered one of the finest builders of dome houses–ones that didn’t leak.

Why did he make this statement?

He went on to explain, that the design of a dome house depended on a single skin being perfect waterproofing technology.  Traditional houses, by comparison, have multiple imperfect layers.  There are overlapping shingles, which keep most of the water out.  Below that there’s a layer of tar paper, which keeps out most of what reaches it.  Then there’s the plywood sheathing, which blocks or absorbs most of what penetrates the tar paper.  Then the attic insulation….

No single layer of this system has to be perfect.

Software testing works the same way.  If you depend on one method of testing, you’re going to leak bugs into production.

If you do unit testing (or micro-testing, as Mike “GeePaw” Hill calls it) of small chunks of code at a low level, you’ll catch most of the coding mistakes.  Then, if you do small scale integration tests of the code that talks to other systems (such as the database), you’ll catch most of the remaining ones.  Then higher level integration or acceptance tests that check that the whole system is wired together right will catch most of those that have escaped so far.  Then exploratory testing….

Any competent network security professional will tell you that you can’t protect your network from malicious people by relying on perimeter security.  You have to bake security into other levels of access, too.

Again, the same is true of testing to protect your application from bugs.

More thoughts on the CST Application Process…

The term “command and control” has become a term of abuse in our community, and on occasion an insult to be used when things are not going our way.  There’s irony in there somewhere, but I can’t quite tease it out.  In the effort to lead a group towards a new CST application process I have been hammered with the said insult, mostly by people who disagree with the proposal I am championing. I can own being pushy sometimes and, you know, wanting stuff to get done, but honestly, I begin hearing “Tobias, you’re so commadncontrol” as a frustrated “Things are not going my way!”.  Either I am blind to my own failings or there is some truth to my observation. Likely a little of both. There is no doubt that creating a new CST application process in a sea of conflicting opinions is massively challenging.

The process that the Scrum Alliance Board of Directors —led in this instance by Mike Cohn— are seeking is one that is objective, transparent and fair, one that all current CSTs will have to go through, as well as all new applicants, and one that is scalable to around 500 applicants per year.  As such it makes certain aspects of the process desired by many existing CSTs to be problematic.

The proposal I am championing is simple. There is only one absolute requirement: to be a Certified Scrum Professional, formally Practitioner (CSP).  Everything else is recommended and weighted, but not mandatory.  This is causing no small amount of opposition from existing CSTs, and a few others who have been mentored by CSTs towards the old process, one that did require co-training, and endorsement by existing CSTs.  Many members of this opposition group want to be gatekeepers of the process in some way, and make sure that only people of their own standard get through.  Mandatory mentoring by an existing CST, and an in-person “test” session to be held in front of a panel of CSTs are uppermost on the opposing agenda.

Why is the idea of having existing CSTs gate the process a bad idea?  Well, aside from the problem that all existing CSTs have to go through the process themselves, the fact is that we, the current Certified Scrum Trainers are just not especially good. Sorry to offend anyone, but it is true.  We are not the cream of the the Agile training world, and there is nothing special about the knowledge of Scrum we each have. We are just a bunch of project managers and developers, with varying degrees of skill and Scrum understanding, and no special teaching or facilitation backgrounds who happened to know the right people at the right time, or apply for the CST designation when the process was weak, or biased, or both.  The arrogance that many in our small community have over their status is quite overwhelming sometimes, as if we have been ordained to be the keepers of all things Scrum.

Be clear, I am talking about the group as a whole. Of course there are some exceptional individuals in the CST group, people who are highly skilled, and quite brilliant in a training context, people who inspire and create internal transformation.  But they are the exception, not the rule.  Most of us are just average.  A good few work hard to improve, and in fact do so.  Others play safe and do what they know.  Outside of the CST community, in the wider Agile world there are many, many skilled trainers, mentors and facilitators of change who are far better than many of us.  I could name a dozen off the top of my head, but I won’t as they may take umbrage to be included in a paragraph with the term “CST” in it (!) Still, despite some historical opposition to the aims of the Scrum Alliance it is these people I am hoping to attract to the Scrum Alliance, to become CSTs, to help us socialize Scrum in more sophisticated, more daring ways to wider audiences.  The new process is being designed to embrace these people as well as those coming to the application through the more traditional path of CST mentoring and co-training.  As the champion of the new process, I would like to lift the average CST ability above mediocre and towards great.

Current CSTs should not be the gatekeepers of the process. We need to seek independent, or at least disinterested assessors to do that job.  And as for this idea of “ordaining” a CST through some sort of initiation ceremony where the applicant has to perform in front of a group of experts pretending to be novice attendees, it is unnecessary, and in poor taste.  And is is brought about by a misconception. The criticism of the proposed process is that it is paper-based, and has no in-person element. This is inaccurate.

People seem to be forgetting that most applicants will have made the effort to co-train multiple times with other trainers (not just CSTs) and will have letters of recommendation from respected people they have collaborated and worked with in real life.  That is the in-person part.  Smart applicants will ask to co-train with good people and to observe their trainings in turn, and talk with them, explore ideas together.  Already experienced trainers won’t need to, and their reputations will speak for them. They have done the groundwork, the in-person work over years that we are asking novice applicants to do in months.  The focus for the experienced trainer will be to know and understand Scrum, and that (I am hoping) will have been determined at the CSP level.  A demo proves nothing.  It is fake, it is demeaning, and it feels like the person is being asked to be a performing monkey, or something. Personally, I hate the idea.

I’d like to see a process where people can apply repeatedly (i.e. each quarter) getting feedback when they fail and continually improving until they pass. To me the feedback and improvement aspect is much more Agile than any proposed stage-gate process. I’d also like to see acceptance be limited to 2 or 3 years and reapplication, or some form of renewal necessary after.  But these are just my thoughts. They are not official Scrum Alliance recommendations. Those are yet to come.

Stay tuned.

Today, I and a colleague finished yet another round of usability studies. This time, we're not going for anything slightly scientific, but just another check-up among others.

The setup is easy, a semi-click able prototype, an open source screen capture program in the form of Cam Studio, a computer with two screens and we're ready to go. I select the users and my colleague has prepared a scenario. He explains for the user the scenario and watches him/her while I sit on the opposite of the table, taking notes and not interfering. As I mentioned, nothing fancy, but I really hope this will be an even more integrated part of our work from now on. Since we're using such light weight methods, we can test a little detail without it becoming expensive.

My colleague is a professional, while I'm not and that we have a professional on board is also so important. The small but important details in how he works makes a big difference on the result. Since I have a tester's and a computer trainer's experience, I can for myself see how I would approached this so differently and how much errors I would have done. I believe that my experience as a trainer and a tester helps me when discussing user experience and I probably stresses these questions more than other project managers, but differentiating between good and not so good solutions is better left to usability studies.

What does not cease to amaze me is how I can never in advance can see the greatest unclarities which the users identify. Of course there are always those areas in which you're struggling, but all those other spots where you haven't even thought there would be a problem, they pop up.

I just wish I started working like this many years ago… 

I had an interesting conversation with a manager the other day about how to gain more insight into changes that are ongoing in the application one of our pilot Scrum teams is working on.  First, what’s the problem?  Group A was doing independent regression for a release and uncovered some ”defects’ that were a result of changes in the application by our Scrum team.  Truth be told, those ‘defects’ are actually de-commissioned functionality.

Manager:  We need to know what’s being changed in the application, we can’t be chasing down defects because of changes we don’t know about.

Me:  Agreed.  We’ve extended the offer for you to come to our end of iteration demos and until this week we haven’t made any changes in existing code so I agree, with these changes we’ll have to invalidate some of the old regression tests that aren’t needed anymore.

Manager: I don’t have time for that.  Is there some type of documentation about the changes?

Me: Yes.  We’ve started using javadocs to document the code and our functional information is in Rally.  Brief, but explains the functionality well enough.  The team members would easily be able to figure out the impact of the changes since they all know the app well enough.

Manager:  I can’t ask my team to waste time sorting through Rally to find this information.

Me: We can export a list for you and email it, it’s a 4 or 5 column XLS with a good summary.

Manager:  Do you know how much email we get?  I can’t agree to that.

Me: Ok, how about you and the members of the other groups who need insight into the changes come to our demos?  We do a 15-minute quick overview before digging deep into the stories we completed.

Manager: They can’t do that, we don’t have approval from their managers to go to your demo.

Me: Ok, we do send a summary of what’s being updated when we make our iteration commitment and we send a summary output after the iteration demo, I can include you on those.

Manager: There’s too much to do, I have to worry about this project, that release, aligning this team with that team, I get too much email now, we need a process.

Me:  Ok, so how about we just have the people from the other groups attend our demo, we’ll give them the 15-minute overview and send the summary of changes before and after the iteration.  If we need to do a more in-depth session, we’re happy to.

Manager: I’ll go talk to the managers to get permission for the other resources to go to the demo.

Me: Great, that should make it easier and really efficient to share information between our Scrum team and the waterfall and regression teams. Thanks!

At the end of the conversation we were right back to where we started.  A quick and efficient session to share knowledge with the people who are programming or testing the software.  I had continued this conversation with a few folks to get to the real problem and the challenges being faces are typical.

So what’s up with all the excuses?  Did we have to fill up the 30 minute time-slot for the meeting to be effective?  I decided to dig deeper:

Q1) Why was the initial response that people couldn’t spare 15 minutes every 2 weeks to get visibility?

A1) Because we are too busy.

Q2) Why are we too too busy?

A2) Because regression testing takes 3 weeks.

Q3) Why does regression testing take 3 weeks?

A3) Because our testing is manual.

Q4) Why is our testing manual?

A4) Because that’s how we do it.

Q5) Why do we choose to do it that way?

A5) Because there are too many projects and we don’t have time to do it another way

I’m sure there were a couple more excuses tossed into that first conversation, I started losing count but the underlying problem of having too many projects in progress at a time are causing a whole host of downstream problems.

At this stage, portfolio management isn’t something we can focus on, especially in a large and complex organization.  First step is to create visibility to outside teams and trim down the regression suite so there is less waste with manual testing.  Our team has already started looking at automating end-to-end regression for happy path scenarios which will also reduce the amount of time spent on manual testing.

It’s a small step, but we need to start somewhere but the message in this post is that things aren’t always as they seem.  The initial response is often a gut-reaction based on stress or other factors and it shouldn’t be confused with resistance to improvement or efficiency gain.