The Real Agility Program – Execution and Delivery Teams

In 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.

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.

To learn more about the sprint review, 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 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

The Rules of Scrum: Your ScrumMaster helps the team expand the definition of “done”

Delivery each Sprint of potentially “shippable” is at the heart of a true Scrum implementation. In order to help the team properly implement Scrum and derive the intended benefits of empirical process control and collaboration with stakeholders, the ScrumMaster needs to help the team expand its definition of done at least until it is able to deliver a potentially complete “shippable” increment of product every Sprint. The ScrumMaster should help the team to revise its definition of “done” every Sprint with the necessary adjustments being made as the result of the Sprint Retrospective. As Scrum teams mature, it is expected that their definitions of “done” will expand to include more stringent criteria for higher quality. The ScrumMaster should always be looking ahead to new ways that the team can expand its definition of “done” in order to deliver higher quality product to the stakeholders and exceed their expectations.

For more information on the definition of done, 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 ScrumMaster consistently avoids doing hands-on technical work with the team

The ScrumMaster is focused on two main goals: to remove obstacles of all sizes and to help the team become better at using Scrum. Both of these jobs require much work and plenty of skill. To do this well the ScrumMaster will need to refrain from doing hands-on technical work. If the ScrumMaster does this then the team will be protected from interruptions, move faster, and feel supported. If the ScrumMaster doesn’t do this then the team will be interrupted often, become slow, and feel unsafe and in harms way. A ScrumMaster doing hands-on technical is wasteful and distracting.

To learn more about ScrumMasters, 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 ScrumMaster has the bandwidth and capacity to respond within minutes to the team’s questions

The ScrumMaster is a full Team Member of the Scrum Team and is required to be focused on helping the team achieve its goals. However, he does not do the work of the Sprint Backlog. Instead he focuses his energies on removing obstacles and helping use Scrum as best as possible. One way to achieve these goals is to be able to respond to questions by the team within minutes. If the ScrumMaster is able to do, the team will move faster, solve problems easier, and cut through obstacles much sooner. If the ScrumMaster is not able to do this, the team will become stalled, frustrated and likely lose trust in the ScrumMaster and the Scrum process.

To learn more about your ScrumMaster, 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