Real Agility – Self-Organizing Team Creation Event for Large-Scale Agile Enterprises

In 2005 I had the privilege to participate in the first occurrence of this fantastic technique for organizing large numbers of people into Agile teams.  It happened at Capital One in Richmond Virginia and my colleague of the time, Kara Silva, led this successful experiment.  The problem was that the “teams” that management had set up didn’t make much sense from an Agile perspective.  They were functional teams (e.g. a team of testers).  But to do Agile well, they needed cross-functional, multi-skilled teams that could work well together to deliver great results each iteration.  So Kara and a few other senior people got together all the staff in the department into a big room with a big whiteboard and facilitated a 3 hour meeting to sort out who would be on which team.  Everyone was involved – all the people who would be on the teams were in the room.  Those teams stayed together with the same membership long after that meeting.

This “team creation event” was a fantastic success for that particular department.  What made it a success?

  1. Everyone participating already had Agile training and experience.  They knew what they were getting into and why they were doing it.
  2. Everyone was encouraged to participate through the way the meeting was facilitated.  No one felt like their opinion was ignored.
  3. The meeting was long, but also time boxed.  It wasn’t an open-ended discussion that could go forever.
  4. It was in-person!!!  Everyone was physically present so that not just abstract facts, but also feelings were clearly visible to everyone else.
  5. It was honest: tough things were discussed including potential personality conflicts.  This open discussion required expert facilitation.
  6. Management was not involved in the decision-making during the meeting.
  7. The overall purpose of the exercise was clear: here’s the business we’re in, and here’s the people we have to work with – how can we organize ourselves to be most effective?
  8. A big diagram of the proposed teams and their membership was constantly being updated on a whiteboard: visual and concrete for everyone to see.
  9. Preparation: the meeting was scheduled far enough in advance that everyone could make it and management was informed about how important it was (don’t schedule over top of it!)

In the Real Agility Program, the team creation event is used to launch a Delivery Group.  The key people at the meeting include all the potential team members as well as the three Real Agility Coaches from the business, from technology, and from process/people.  Depending on the number of people involved, the team creation event can take anywhere from two hours up to a full day.  Longer is not recommended.  For larger Delivery Groups, we recommend that the team creation event be held off-site.

Facilitation of the team creation event is usually done by the process/people Real Agility Coach.  If you wanted to use this process with other enterprise Agile frameworks such as SAFe (Scaled Agile Framework) you would have the “equivalent” person such as SAFe’s Release Train Engineer as the facilitator.

The team creation event should only be done when the business is ready to get a Delivery Group started on actual product, project or program work.  If there is any significant delay between the team creation event and the launch of the Delivery Group on it’s work, then the teams can fracture and you may need to run the event again.  A few days should be the maximum delay.

One client we worked with ran the team creation event but had some significant problems afterward because they weren’t really ready.  In particular, they still had to make staffing changes (primarily letting go of some contractors, hiring some new full-time employees).  As a result, the teams created in the team creation event were not really properly stable.  This caused a great deal of disruption and even significant morale problems for some teams.  It is essential that the Leadership Team be committed to keeping the team membership stable for a significant period of time after the team creation event.  That includes any necessary means to encourage people who are thinking of leaving to reconsider.  It also includes a commitment from leadership to respect the self-organizing choices made during the team creation event unless there is an extremely urgent problem with the results.

So, to make it systematic, here are the steps required to run a team creation event:

PREPARATION

  1. Make sure that everyone who will participate has Agile training and has been on an Agile team for at least a few iterations/sprints/cycles.
  2. The Leadership Team needs to publish a notice (usually through email) explaining the upcoming team creation event and their unqualified support for the event.
  3. The people/process Real Agility Coach needs to schedule the time for the event, and if necessary, book the venue.
  4. In the weeks and days leading up to the event, some communication should be provided to all the participants about the overall business purpose of the Delivery Group.  Is it for a specific Program?  If so, what is the objective of the program from a business perspective?  It should not just be a one-time communication.  This should come from the business Real Agility Coach.
  5. The Leadership Team needs to decide which management stakeholders will attend the team creation event and make presentations.  These presentations should be about setting a vision for the Delivery Group, not about assigning people to teams.

TEAM CREATION EVENT AGENDA

  1. The team creation event starts with the people/process Real Agility Coach welcoming people and reiterating the purpose of the event.
  2. Management stakeholders make their presentations to ensure that participants have a clear vision.
  3. The business Real Agility Coach summarizes the vision presented by the management stakeholders.
  4. The people/process Real Agility Coach provides instructions about the constraints for a good Agile Delivery Team:
    • Cross-functional
    • Multi-skilled (see the Skills Matrix tool for ideas here).
    • Correct size (usually 7 +/- 2).
    • People who want to work with each other.
    • People who want to work on that particular team’s goal (if such is set).
    • Everyone must be on a team.
    • Every team must choose the people who will fill the Agile Delivery Team roles (e.g. ScrumMaster and Product owner for Scrum Delivery Teams).
  5. Everyone starts self-organizing!  Usually the three Real Agility Coaches circulate through the teams as they are working to organize themselves to offer gentle guidance, to answer questions, and to see if there are opportunities to optimize across teams.  These optimization opportunities should always be offered as suggestions rather than being directive.
  6. As the self-organization is happening, the people/process Real Agility Coach needs to clearly indicate the passage of time so that people are “finished” when the time has run out.
  7. Once the self-organizing is done, the Leadership Team (or a representative) thanks everyone for their work in creating the teams and agrees to let everyone know within a short period of time if there are any changes required (to be done before the teams start working).
  8. The people/process Real Agility Coach closes the meeting.  It is critical to record the final results of who is on which team.  It may be easiest to get the teams themselves to do this before leaving the meeting.

FOLLOW-UP

  1. The people/process Real Agility Coach makes sure that the Leadership Team receives a complete and accurate record of the results of the team creation event before the end of the day.
  2. The Leadership Team reviews the results and makes any (minor but critical) adjustments within a few days, at most, and publishes the final list to everyone.  Failure to do this in a timely manner can deeply demoralize the staff who will be in the Delivery Group.
  3. Any updates to org charts, management tools, time tracking tools, job descriptions, etc. that need to reflect the new team organization should also be made immediately and certainly before the Delivery Group starts working.
  4. A final thank you message from the Leadership team should be delivered immediately prior to the start of the Delivery Group doing its work.

Have you experienced an event like this? Did it work? What was different from what I described?

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Scrum “Inputs”

The Product Backlog is often described as the primary input to Scrum.  The Sprint starts with Sprint Planning and Sprint Planning starts with the Product Owner and the Product Backlog.  In principle, this makes perfect sense and hopefully it is enough for most teams and organizations to just start with the Product Backlog.  And if you don’t have a Product Backlog, then just start without one, get some stuff done that the team thinks is important, invite some people to the Sprint Review and most likely one of those people will end up becoming the Product Owner and gradually take on the responsbilities of that role.  I believe in just starting if you can.  I even wrote a blog post about this a while back and I stand by it.

I have served as a Scrum Master and coach for a number of teams and I have identified some patterns that I think are worth addressing.  Newly-formed teams tend to ask for (and need) a little more help than this in order to feel ready to start.  And I have learned from experience that it is usually more effective for the adoption of Scrum and team development for the team to feel ready enough to just start.

The Scrum Guide recognizes the following inputs to Sprint Planning:

  • Product Backlog
  • Latest product increment (not applicable to first Sprint)
  • Projected capacity of the Development Team during the Sprint
  • Past performance of the Development Team (not applicable to first Sprint)
  • Definition of “Done” (implicitly)

A newly-formed team often needs to address the following before the first Sprint:

  • Product Backlog
  • Projected capacity of the Development Team during the Sprint
  • Definition of “Done”

If these are not addressed before the first Sprint, then they will likely need to be addressed during Sprint Planning, which can place a lot pressure on a new team (especially in environments where it is difficult to build shared understanding of the work).

Product Backlog

Keep it simple.  It’s an ordered list of all the features, functions, enhancements and fixes that might be needed in the end product.  Get the Product Owner to blow these things out into a list.  It doesn’t need to be a complete list.  Just the most important things right now.  A good test is to give the Product Owner 5 minutes.  Whatever the Product Owner can think of in 5 minutes is important enough for the team to start working on.  There are all kinds of techniques that can be used to order the Product Backlog.  The simplest way is to just have the Product Owner eyeball it.  If people are uncomfortable with this, then introduce the other ways.  It doesn’t need to be perfect.  It will get better and become refined and adapted as you go.

Projected capacity of the Development Team during the Sprint

Multiply the number of working days in the Sprint (total days minus Sprint Planning, Sprint Review and Sprint Retrospective, rounding down) by the number of Development Team members by the average percentage team member dedication (hopefully 100%).  If you have weird things going on with team member allocation (not 100%) then you may find it helpful to refer to this blog post.  According to what the Scrum Guide says about Development Team size and Sprint duration, this number could theoretically be smaller (Sprint less than one week), but in most cases no less than 12 (3-member Development Team in a one-week Sprint) and no more than 207 (9-member Development Team in a one-month Sprint with 23 days – the maximum number of weekdays in a month).

Definition of “Done”

This is a list of all of the activities that will go into the intended Increment of the first Sprint in order for it to be done.  The team needs to know this before it can estimate the items in the Product Backlog as a team.  Estimation is not a requirement of Scrum, but is often very helpful in refining the Product Backlog, tracking velocity and making projections into the future based on historical actuals.

Planning with the Product Backlog, projected capacity and Definition of “Done”

In the first part of Sprint Planning, the team looks at the items at the top of the Product Backlog in order to determine what can be done in the Sprint and the Sprint Goal, keeping in mind that it will need to complete the items according to its Definition of “Done”.  Once the team has set a Sprint Goal, it can then create a set of tasks that represent how the work will get done.  All of the tasks should fulfill a specific attribute of the Definition of “Done” or be about the technical parts of the system that need to be built.  The team should try to create a set of tasks each of which are a one-person day effort or less.  Count the number of tasks.  If the number of tasks are close to the number of days of the team’s capacity, the team can be confident that it has a decent Sprint Backlog.  If not, then the the Sprint Backlog and likely the Sprint Goal will need to be adapted.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Theoretical Team Member Allocation Adjustment for Team Capacity Adaptation Projections Game: Adaptive Planning for Adjusted Team Capacity in Scrum

Author’s caveat:

Lots of smart people have already come up with lots of ways of doing adaptive planning, and chances are someone has already come up with some variation of this particular approach. I have not yet had the benefit of reading everything that everyone else has already written about Agile and planning, so this has been generated by my own experiential learning on the ground as an Agile coach.  Sometimes, as a ScrumMaster/Agile Coach, you are called upon to be a two-trick pony.  This is my other trick.

 Requirements for team estimation (and planning):

  • Product Owner
  • The whole Development Team (i.e. everyone who will be involved in doing the work)
  • Product Backlog
  • Definition of “Done”

 When team membership changes:

A Scrum Team that is estimating effort against Product Backlog items for project planning and timeline projections and changes team membership for one or more Sprints must also re-estimate the remaining items (or at least the items that will be part of the Sprints in which the different/additional team members are expected to participate) regardless of estimation method (Agile Planning Poker or otherwise). The people involved in doing the work (Development Team members/Sprint) must also be involved in providing team estimates. The Development Team is responsible for all estimates as a whole team and therefore should provide estimates as a whole team. The Planning Poker game is widely understood by Agile experts and successful Agile teams as the best tool for facilitating team estimation. Part of what makes Planning Poker so effective is that it does not only provide accurate timelines, but it also facilitates knowledge-sharing among team members as everyone on the team is required to endeavor to understand the degree of complexity of the work of all other team members in order to deliver each item according to the team’s Definition of “Done”.

When team member allocation is adjusted:

Sometimes, the Development team will have people partially dedicated to the team. After one or two Sprints, it becomes apparent that full dedication of all Development Team members is required for optimal team performance. As result, management can be assisted to reconsider allocation of team members towards 100% dedication to the work of a single Scrum Team. Increased (or decreased) dedication of team members can also be expected to have a corresponding impact on velocity (effort points completed per Sprint). However, the Scrum Master needs to help the team (and their managers) to be careful to avoid planning against the unknown. Scrum allows a team to adapt based on actual historical data. Therefore, planning against minimum historical velocity is strongly recommended as a general best practice. At the same time, if a team starts off with, say, 50% allocation of team members and management decides to bump it up to 100%, it is fairly safe to assume that you will actually get somewhat more out of the team. How much more is never possible to know, as human beings are reliably incapable of predicting the future. The moderate way to approach this is to plan the next Sprint based on previous velocity, finish the planned work early in the Sprint, get a bunch of “extra” stuff done, then calculate velocity of the new and improved team and plan against the new and improved velocity. This allows the team to adapt to actuals and not be blind-sided by unforeseen impediments/bottlenecks.

Sometimes, there is a need for management to get a sense of how much more velocity the team will get from increased team member allocation in order to feel that an informed decision has been made. There is a simple (though not risk-free) method for doing this that I have whipped up after being put on the spot on several occasions. I have decided to call this the Theoretical Team Member Allocation Adjustment for Team Capacity Adaptation Projections Game.

WARNING:

The purpose of this exercise is to provide decision-makers with a sense of how much they are going to get out of adjusted allocation of team members to Scrum Teams. Scrum Teams perform optimally when all team members are 100% dedicated to the team. This game should be used with caution and as a means to help organizations move closer to 100% dedication of all Scrum Team members (at least all Development Team members) and, therefore, eliminate the need for this game. Great care should be taken to not encourage perpetuation of dysfunctional Waterfall habits such as “we will now go twice as fast and get done twice as early with twice the allocation of resources because we have this shiny new crystal ball called Theoretical Team Member Allocation Adjustment for Team Capacity Adaptation Projections Game that tells us so.” As long as no one believes that this is magic, it is likely safe enough to proceed to Step 1.

Step 1 – What is our current velocity?

After the first Sprint, the team should be able to count up the number of Product Backlog items completed and add up the corresponding number of “Effort Points” established during its initial estimation (Planning Poker) sessions. Let’s say for our example that the number completed for Sprint 1 is 21 Effort Points. Therefore, the current velocity of the team is 21. Let’s say that this is not a comfortable realization for the team because at some point in the past it had been estimated that this project would take the team about 5 Sprints to complete. Now, the team has done 21 points in the first Sprint and the total number of Effort Points on the Product Backlog estimated by the team is just under 210. Uh oh… 10 Sprints! Whoops! Now what do we do?! Are the new estimation values wrong? Should we stick to the 5 weeks and just have everyone work overtime on this project? Should we take this to management? Let’s say that this team decides to take it to management. But what if management needs more information than “team velocity = 21, Product Backlog = 210, therefore it’s going to take us 10 Sprints instead of 5”? Never fear, Theoretical Team Member Allocation Adjustment for Team Capacity Adaptation Projections Game is here!

Step 2 – What is our current capacity?

As part of Sprint Planning, the team needs to have a sense of its capacity in order to create the Sprint Goal and Sprint Backlog. Therefore, the team should already have a sense of its own capacity. Let’s say for our example that the (fictional) Development Team had the following projected allocation for the first Sprint:

50%        Chris P. Codemuncher

50%        Larry Legassifulunch

25%        Beth Breaksidal

40%        Gertrude Gamesthadox

40%        Dana Deadlinedryver

The team is doing 2-week Sprints. After calculating the time that the team has allocated for Scrum Events, the remaining time for doing the work of the Sprint is about 8.5 days. Therefore, we can calculate the total allocated days per team member as such:

8.5 x 50% = 4.25 days    Chris P. Codemuncher

8.5 x 50% = 4.25 days    Larry Legassifulunch

8.5 x 25% = 2.13 days    Beth Breaksidal

8.5 x 40% = 3.4 days      Gertrude Gamesthadox

8.5 x 40% = 3.4 days      Dana Deadlinedryver

17.43                              Total combined available days per Sprint

Let’s round that down to 17. That’s the number used by the team to understand its capacity for Sprint Planning. This is a powerful number for other reasons than what we are trying to get at here, but they are worth pointing out nonetheless. For generating the Sprint Backlog in Sprint Planning, this is particularly useful if each task in the Sprint Backlog is a maximum of a one-person-day. Therefore, this team should have a minimum of 17 tasks in the Sprint Backlog and these tasks should all be a one-person-day or less amount of effort. If the team has more than 17 tasks which are all about a one-person-day of effort, chances are the team has overcommitted and will fail to deliver the Sprint Goal. This should trigger the adaptation of the Sprint Goal. In any case, it provides the team with simple transparency that can easily be inspected and adapted throughout the Sprint. For example, with one-person day tasks, each team member should be able to move at least one task into the “Done” position every day and point to that movement every day during the Daily Scrum. Also, this team should be burning down at least 5 tasks every day. If either of these fails to occur, this is a clear signal for the team to inspect and adapt.

Now, let’s get back to our Theoretical Team Member Allocation Adjustment for Team Capacity Adaptation Projections Game. As a result of Steps 1 & 2 we now know that the team’s velocity is 21 Effort Points and that the team’s capacity is 17 person-days per Sprint. For short, we can say:

21            Velocity

17            Capacity

21/17       V/C

(WARNING: This number is dangerous when in the wrong hands and used as a management metric for team performance)

 Step 3 – How much capacity do we hope to have in the next Sprint?

Let’s say a friendly manager comes along and says “you know what, I want to help you guys get closer to your original wishful thinking of 5 Sprints. Therefore, I’m deciding to allocate more of certain team members’ time to this project. Unfortunately, I can only help you with the ‘developers’, because everyone else reports to other managers. I’m concerned that Beth is going to become a bottleneck, so someone should also speak with her manager. But for now, let’s bump Chris up to 100% and Larry up to 75% and see what that does for you. We’re also going to throw in another ‘specialist developer’ that you need for some stuff in your Product Backlog at 100%. How much more velocity can I get for that?”

Okay. So…more allocation = more capacity = more velocity, right? If we acknowledge that this is highly theoretical, and remember the initial WARNING of the game, we can proceed with caution…

But just as we get started on calculating the adjusted allocation of team members, we find out that Beth was actually more like 50% allocated, Dana was more like 15% allocated and Gertrude was more like 30% allocated. We need to recalculate our actuals for Sprint 1:

8.5 x 50% = 4.25 days    Chris P. Codemuncher

8.5 x 50% = 4.25 days    Larry Legassifulunch

8.5 x 50% = 4.25 days     Beth Breaksidal

8.5 x 30% = 2.55 days     Gertrude Gamesthadox

8.5 x 15% = 1.28 days     Dana Deadlinedryver

16.58                               Total combined ACTUAL available days in Sprint 1

16                                    Actual capacity (rounded-down)

21/16                               Actual V/C

As a side note, Beth had to work on a Saturday in order to increase her capacity but she spoke with her manager and thinks that from now on she will probably be able to maintain this degree of dedication to the team without having to work any more overtime.

Now the team can calculate its hoped-for capacity for Sprint 2 and beyond:

8.5 x 100% = 8.5 days     Sally Supaspeshalis

8.5 x 100% = 8.5 days     Chris P. Codemuncher

8.5 x 75% = 6.38 days     Larry Legassifulunch

8.5 x 50% = 4.25 days     Beth Breaksidal

8.5 x 30% = 2.55 days     Gertrude Gamesthadox

8.5 x 0% = 0 days            Dana Deadlinedryver

(Note: Dana is also the Scrum Master with plenty of other work to do for the team)

30.18                               Total combined hoped-for available days in Sprint 1

30                                     Hoped-for capacity (rounded-down)

Step 4 – How much velocity do we hope to have in the next Sprint?

21            Actual Historical Velocity

16            Actual Historical Capacity

30            Hoped-For Future Capacity

x              Hoped-For Future Velocity

Some simple math, loaded with assumptions:

Actual Historical Velocity/Actual Historical Capacity = Hoped-For Future Velocity/Hoped-For Future Capacity

Therefore if 21/16 = x/30, then x = 21 x 30/16 = 39.375

39            Hoped-For Future Velocity

Step 5 – How do we adapt our planning in light of what we now know (assuming we now know something substantial enough to inform our planning)?

Hopefully, not much. The best thing for the team to do at this point is to plan against its actual historical velocity of 21. If team members finish their work in the Sprint Backlog early, they should help out with other tasks until the Sprint Goal is delivered. Then, if the team achieves the Sprint Goal early and has extra time left before the end of the Sprint, then the team can pull additional items to work on from the Product Backlog. If the velocity of the team actually increases as a result of actual increased capacity, then the team can safely plan against its increased velocity beginning in Sprint 3. However, Hoped-For Future Velocity is often way too tantalizing for a team that already strongly (and to some extent, logically) believes that it can get more done with more capacity. So, most teams will usually plan to do more in light of this knowledge and that’s fine. Scrum allows them to inspect and adapt this plan at least every day. The team will figure it out.

Thank you for playing Theoretical Team Member Allocation Adjustment for Team Capacity Adaptation Projections Game. I hope it was as fun to play as it was to create!

See you next time,

Travis.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Real Agility Program – Execution and Delivery Teams

Execution IconIn a recent post, Mishkin outlined the Leadership Team component of the Real Agility Program.  While the Leadership Team track focuses on developing leadership capacity for sustained transformation, The Execution track focuses on launching and developing high-performance project, product and operational teams.  This track is the one that most of our clients use when they run Agile pilot programs and is a critical component of getting quick wins for the organization.

Groundbreaking works such as The Wisdom of Teams (Katzenbach & Smith), The Five Dysfunctions of a Team (Lencioni) and Drive (Pink) have served well to distill the essential requirements of high-performance teams.  Scrum, Kanban, and OpenAgile are proven frameworks that optimize the value of teams and create the necessary working agreements to help teams reach that high-performance state.

The Delivery Team track of the Real Agility Program creates new, cross-functional, multi-skilled, staff-level teams of willing individuals.  These teams are responsible for delivering value—business results and quality.  Individuals are committed to the performance of the team and the organization.  Teams develop the capacity to self-organize and focus on continuous improvement and learning.  A team is usually composed of people from various roles at the delivery level.  For example, and IT project team might be composed of people whose previous* roles were:

  1. Project manager
  2. Business analyst
  3. Software developer
  4. Tester
  5. Database developer
  6. Team lead
  7. User experience lead
  8. Intern

* These roles do not get carried into the new delivery team other than as a set of skills.

The track begins with establishing pre-conditions for success including executive sponsorship, availability of team members and management support.  Team launch involves a series of on-the-job team development workshops designed to enable the teams to create their own set of values, working agreements and high-performance goals.  Teams are guided in the creation of their initial work backlogs, defining “done”, estimation and planning and self-awareness through the use of a collaborative skills matrix.  The teams are also assisted in setting up collocated team rooms and other tools to optimize communication and productivity.

Qualified coaches assist the teams to overcome common issues such as personal commitment, initial discomfort with physical colocation, communication challenges of working with new people in a new way, management interference and disruptions and appropriate allocation of authority.  This assistance is delivered on a regular schedule as the team progresses through a series of steps in the Execution track process.  Usually, these steps take one or two weeks each, but sometimes they take longer.  A team that needs to get to a high-performance state quickly might go through the entire program in 10 or 12 weeks.  In an organization where there is not the same urgency, it can take up to a year to get through the steps of the track.

The coaches for this Execution track also help management to resist and overcome the strong urge to manage the problems of the teams for them.  In order to develop through the stages of team development, teams need to be effectively guided and encouraged to solve their own problems and chart their own courses towards high-performance.

The goal of the Execution track of the Real Agility Program is to help the team go through the stages of forming-storming-norming and set them up to succeed in becoming a high-performance team.  Of course, to do this requires some investment of time.  Although the Execution track is meant to be done as on-the-job coaching, there is a 5% to 20% level of overhead related to the Real Agility Program materials themselves.

See also the article on the Recommendations component of the Real Agility Program.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Back to the Basics: Coding and TDD

I’ve been working for the past year on building the Scrum Team Assessment (yes, you can still go get it for your team :-) ).  I’ve been doing all the work on it personally and it has been great fun.  The best part of it has been that I’m back into coding.  And, with that, of course I have had to take my own advice about Test-Driven Development and the other Agile Engineering Practices.  But it hasn’t been easy!

I’m using PHP for the web front end, and Python with OpenERP for the back end.  My testing tools include Selenium for Acceptance Testing and PHPUnit for unit testing.  And… nothing yet for the Python back-end.  This is still a sore point with me.  Normally, I would find the back end TDD process easier… but OpenERP has been a HORRIBLE BEAST to use as a development platform.  Well, I might exaggerate a bit on that, because it is really just the complete lack of well-written API documentation and sample code.  Which is funny, because there are tons of open-source extensions for OpenERP written.  Anyway, I don’t want to complain about it too much, because in many other ways it is a fantastic platform and I wouldn’t easily switch it for anything else at this point.

Back to testing.  Last week, a client using the Scrum Team Assessment found a bug… and it was one of those ones that I know made them consider not using the tool anymore. Fortunately, our contact there has the patience of a Redwood, and is helping us through the process of fixing the system.  How did the bug happen?

Because I didn’t do _enough_ TDD.  I skimped.  I took shortcuts.  I didn’t use it for every single line of code written.

<Failure Bow>

The question for me now, is “why”?  Fortunately, the answer is simple to find… but solving it is not as easy as I would like.  I didn’t follow my own advice because I was learning about too many things at the same time.  Here’s what I was learning all at once over a three week period in December when I was doing the real heads-down development work:

  1. PHP and PHPUnit
  2. Python
  3. OpenERP (APIs for persistence and business logic)
  4. RML (a report generation language)
  5. Amazon EC2, RDS and Route 53
  6. Some Ubuntu sys admin stuff
  7. VMWare Fusion and using VMs to create a dev environment
  8. Postgresql database migration
  9. Oh, and refreshing on Selenium

Like I said, FUN!  But, a bit overwhelming for someone who hasn’t done any significant development work since 2006-ish.  As well, because of learning about so many things, I also didn’t have a good setup for my development, testing and production environments.  Now I have to clean up.  Finally, I also forgot about another important Agile Engineering practice that is used when you have lots of intense learning: the Architectural Spike.

I have to make sure that I take all that I’ve learned and create a truly good dev and test environment (because that was a huge hinderance to my work with both Selenium and PHPUnit).  And I have to take the time to learn to do the testing in Python (I would love suggestions on a good unit test framework)… and go back over that code, even though most of it is simply declarative of data structures, and make sure it is well-covered by unit tests.  Ideally, I might even consider throwing some code away and starting from scratch.  One possibility I’ve considered is to get rid of PHP entirely and build the whole system with Python (I’d love some thoughts on that too!)

Why am I doing all this?  Well, I really think that the Scrum Team Assessment is an awesome tool for teams that maybe can’t afford a full-time coach.  It certainly isn’t a complete replacement, but I’ve poured my knowledge and experience into it in the hopes that it can help a bunch of people out there do Scrum better… and more importantly, create great teams that produce awesome business results and where people love to come to work every day.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Updated: Planning Game for Agile Estimation

I’ve made a minor update to my article about Agile Estimation with the Planning Game to include a downloadable pdf of the article for easy printing.  The downloadable version also includes a tiny bit of commentary that comes from my upcoming Agile Advice book.  There are also two links added at the end of the article.  One is the the wikipedia article about Planning Poker (which describes the method slightly differently), and the other is to an article I wrote a long time ago about the wideband delphi estimation method.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Start of a True Team

I wrote this article for our Real Agility Newsletter, but I wanted to share it here too, just in case some of you don’t get it.  I think this is important to share because it gets to some of the deep values of Agile and good teamwork.

- – - – - – - -

The team really is important. Last month I wrote about love. This month, I’ll write about commitment. Our team has gone through some extreme tests this last month. Commitment kept us together.

Our business has been through crisis before. In the second half of 2005, my own financial mis-management led to near-bankruptcy for the business and for myself personally. My dear long-suffering wife and business partner, Melanie, kept things under control as we recovered. In late 2009 the Great Recession hit us hard and we had to cut our staff back to just Paul and myself by laying off three talented friends and cutting work to a loyal subcontractor. That was incredibly painful for everyone involved. A similar crisis occurred again in late 2011, although it wasn’t as severe. In September last year, our projections were showing a looming crisis… but we narrowly averted any layoffs when a smaller consulting deal closed and one person was let go for unrelated reasons. We still needed more work, and in late fall we were expecting to close three important deals.

In January we knew we were in trouble. Business was not booming. In fact, those three important deals had fallen through with nothing obvious on the horizon to replace them. Our office management was in a shambles with two recent changes in staff and very little continuity. Our accounts receivable had several items that were waaaay overdue. We were starting to dig deep into our operating credit with no obvious way to climb back out. The partners, Paul, Travis, Melanie and I started to talk about serious stuff: deep layoffs. We were worried we may even have to cut all the way back to just me doing work (mostly CSM classes) – a staff level we haven’t seen since 2007!

Two weeks ago, the four partners had an emergency weekend meeting after our early February attempts to build sufficient immediate cash flow failed. We consulted for over four hours around a single question: what should we do? Our projections were showing us running out of credit in just four weeks, our business development pipeline was almost empty and the few things in it were clearly long-shot deals, at least in the timeframe we needed. It seemed almost impossible to avoid deep layoffs. Our love for each other seemed almost irrelevant to the crisis, despite the depth of our feeling.  The consultation was difficult and filled with despair.

My memory for exact words is poor. I remember concepts, relationships and feelings. During that weekend consultation, one thing really stood out: we started to talk about commitment. We talked about what it would mean to be committed to each other and to the business vision of transforming people, process and culture. Most powerfully, we talked about the commitment of our newest employee, Nima, who seemed determined to go to the ends of the earth, to the very last moment to help us all succeed. As we talked about commitment, we came to our most powerful decision: sink or swim, we are all in this together to the end.

After that critical point in our discussion, we set some goals, determined some important activities, and decided to go literally day-to-day in deciding if it was time to wrap up the business. And, strangely enough (I say ironically), we decided we needed to shorten our planning cycle from a month to two weeks, increase the discipline of our team’s interactions to bi-daily check-ins, create a detailed set of dynamic plans for the two weeks, and have a review meeting at the end of the two weeks. Sounds a bit like an Agile team, doesn’t it?

What happened? Well, we’re still around. We’ve closed enough business that our projections are now showing us staying in a steady state financially for the next three months. That’s a dramatic turnaround from just two weeks prior. We aren’t going to run out of credit. In fact, we now have enough prospects that we expect to be extremely busy in just a couple more weeks. Our end-of-cycle review, which happened on Friday, was still difficult. There is still great uncertainty about many things. But the one thing that is crystal clear, strong as steel, and deep as the deepest ocean is our commitment to each other to succeed together. We are a true team.

- – - – - – - -

If you have similar stories to tell, I would love to hear them!

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: Your Product Owner creates and maintains the team’s Product or Release burndown chart

The Product burndown chart tracks the amount of work remaining in the Product Backlog Sprint-by-Sprint. This burndown chart is updated every Sprint and is visible to the Scrum Team and its stakeholders. This activity is part of the Product Owners duty to facilitate transparency around value delivered over time. The Product Owner is responsible for making the overall progress of the work visible to the Scrum Team and other stakeholders. This activity is part of the Product Owners job to satisfy stakeholders as it allows them to easily see how the Scrum Team is trending on planned deliverables. This information allows the team and the Product Owner to discuss any necessary adjustments to the team’s plans for the upcoming Sprints in a timely fashion. What happens if the Product Owner fails to create and/or maintain the team’s Product burndown chart? Most likely we will be unable to see if the team is on track, late or early in its delivery of value. In a traditional waterfall approach we would find out this information near the end of the project which is much too late. Also, without regular updates on the trend of the team it is highly probable that stakeholders and/or team members may slip back into an individualistic approach to work instead a team based approach.

To learn more about Product Owners, visit the Scrum Team Assessment.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: Your Product Owner never tells the team how to solve a technical problem

Solving technical problems is the job of the product developers on the Scrum Team, not the Product Owner. The Product Owner is responsible for the product from a business and user perspective and has authority over the team only in this limited realm. By overstepping the bounds of authority in this way, the Product Owner becomes an obstacle for the team by reducing its ability to self-organize. A Product Owner who is part of a team that has reached a high-performance state may be able to safely make technical suggestions, but should always be careful not to push the team to accept those suggestions.

To learn more about Product Owners, visit the Scrum Team Assessment.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: Your Product Owner never does hands-on technical work with the team

The Product Owner’s main responsibility is to maintain the Product Backlog through direct communication with the users and stakeholders. To do this well it will take most of his time and effort to be effective. Hands-on technical is done by the Team Members not the Product Owner since this is not the Product Owner’s strength or area of expertise. If the Product Owner refrains from doing the hands-on technical work, then he is able to provide the vision and share the “what” that the team needs to accomplish. If not, he will be bogged down by the tasks and lose the time and ability to provide product guidance and connect with the stakeholders.

To learn more about Product Owners, visit the Scrum Team Assessment.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: Your Product Owner has the bandwidth and capacity to respond within minutes to the team’s questions

The Product Owner needs to be highly available to the Scrum Team. If the Scrum Team has a question about a Product Backlog Item, then the Product Owner should be able to respond within minutes to that question. Responding this quickly ensures that the Team is building the Product in a way that best satisfies the Product Owner. In particular, it helps to avoid surprises about basic aspects of the Product during the Sprint Review Meeting that then lead to wasteful changes or re-work. If the Product Owner does not have this level of availability, it may not cause any immediate problems, particularly if there are other team members who know the business and the product well. However, since Scrum holds the Product Owner accountable for what is built, it is often better for the Team to check its assumptions with the Product Owner.

To learn more about Product Owners, visit the Scrum Team Assessment.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: Your Product Owner is the sole and final decision-maker for when the team’s work is released to production, users or customers

The Product Owner has the sole authority on putting the work of the Scrum Team at the end of a Sprint into the hands of users. This means that at the end of a Sprint, after the Sprint Review has occurred, the Product Owner considers the state of the Product (features, quality, performance, etc.) and the state of the business/market, and decides if the product should be sent out. In an IT or web environment, this means deployment. For other types of software this might be live updates or sending out DVDs to customers. There should be no other individuals who have the authority to do extra releases without the Product Owners approval, nor should there be anyone who can stop a release from going out if the Product Owner makes that decision. If the Product Owner has this authority, it can create a high level of efficiency in addressing the needs of the business or the needs of the market. If the Product Owner does not have this authority, then it undermines their authority over the ordering of the Product Backlog (since that ordering becomes meaningless) and it undermines the broader organization’s ability to hold the Product Owner accountable for results.

To learn more about Product Owners, visit the Scrum Team Assessment.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: Your Product Owner is allowed to communicate directly with any stakeholder of the team

The Product Owner needs to be in contact with all those that are invested in the work of the team (aka stakeholders). These stakeholders have information on the marketplace, the users’ needs, and the business needs. The Product Owner must be able to communicate with each of these individuals whenever the need arises. If this is possible, the entire Scrum Team will have the most up to date information that will aid them in their execution of the product. If not, the team will have to wait for information and/or guess which will cause confusion, blame, distrust, and unhappy customers.

To learn more about Product Owners, visit the Scrum Team Assessment.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: Your Product Owner uses the Sprint Review to help the team continuously improve the product

The Sprint Review is a key meeting for the team to improve the product. There are three main purposes of the Sprint Review: inspect how the last Sprint went with regards to the product; identify the items that are complete and order any potential changes; and, integrate those changes into the Product Backlog. This meeting aids the team in inspecting and adapting the entire product increment and how the team is progressing towards any deadlines. The Sprint Review is a check point that helps the Scrum Team to know the product’s current state, compare to its desired state, identify gaps, and take the needed steps to improve. This meeting is also where the Product Owner challenges the Scrum Team to look at the product clearly (it’s not just for the stakeholders!). When a Scrum Team refrains from having and participating in this essential meeting, the is team is likely to become a Scrum Team in name only without any of the far reaching benefits that many other Scrum Teams have experienced. A demonstration of the Product Backlog Items completed in the Sprint is often a part of this meeting.

What is the main purpose of the Sprint Review? Bottom line: to get feedback on how well the work the team is doing will satisfy business needs.  If the team isn’t getting that feedback in a practical concrete form, then the Sprint Review needs to be improved.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: Your ScrumMaster creates and maintains the team’s Sprint burndown chart

The Sprint burndown chart tracks the amount of work remaining in the Sprint day-by-day. The burndown chart is updated daily and is visible to the team and stakeholders. This activity is part of the ScrumMaster’s duty to facilitate the Scrum Process. This activity is part of the ScrumMaster’s job to satisfy stakeholders as the chart allows the team to easily see how it is trending on committed deliverables. This information allows the team and the Product Owner to discuss any necessary adjustments to the team’s commitments for the current Sprint in a timely fashion. What happens if the ScrumMaster fails to create and/or maintain the team’s Sprint burndown chart? Most likely we will be unable to see if the team is on track, late or early in its current Sprint. To find out this information we would have to wait until the Sprint is done which is much too late. Also, without daily updates on the trend of the team it is more likely that Scrum Team Members may slip back into an individualistic approach to work instead a team based approach.

For more information about the turndown chart, visit the Scrum Team Assessment.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail