Just Start!

Learn more about transforming people, process and culture with the Real Agility Program

I have heard many reasons why a new team should wait to start “doing” Agile.  Recently, I was asked to help a group who was struggling to get a Scrum team started.  They had real obstacles to overcome, but waiting wasn’t helping them.

This group was part of an IT initiative to develop a business intelligence program for a large energy company.  The existing processes were highly inefficient and wasteful.  The losses were in the ballpark of $1M/day.  There was a long history of failed solutions.  Needless to say, this was a critical project.

Those of us who understand Scrum well know that the more critical a project is, the more urgent it is to get a team up and running as early as possible.  Unfortunately for this group, there was a great deal of cultural inertia from the IT management holding them back, including chronic distrust between IT & business leadership.  IT management perceived Agile to be a risk and a threat.  They were tolerating it as a “pilot project”.  They wanted to be sure that when Agile failed, they would not be left holding the bag.  Their solution for self-preservation was to insist on getting the architecture of the system in place before the team started to work on features.

The only developer that management trusted with the initial architecture work was also extremely busy working on other projects.  This individual and several other people slated to be on the new Scrum team were tied up working on change requests for a Waterfall project with no clear end in sight.  It seemed impossible to predict when the system architecture work might begin, let alone end.

Meanwhile, the Product Owner was waiting for some new functionality that he could use and show to his superiors—the stakeholders that he reported to in the business.  The program manager, who was the champion of the Scrum implementation, understood Scrum to be the way to succeed.  The first Scrum team was wrapping up on the first project in the new program and the business was happy with the process and the results.  This confirmed his understanding and gave him some traction to move forward.  But he didn’t have authority over all of the slated team members (specifically the sole developer trusted by IT management) to start.

I tried to explore possibilities of moving forward with the program manager.  The conversation went something like this:

TB: Are there some people who are available to start as the team for the new project?

PM: Yes.

TB: Great!  Do you need the star developer on this project or are there other people who have the skills to do the work who could be on the team?

PM: There are other people with skills who are available and who could be on the team.

TB: Great!  Do you have the authority to make that happen?

PM: Yes.

TB: Great!  Can we have the first Planning Meeting tomorrow?

PM: Yes.

TB: Great!  What time do we start?…

One might get the impression from reading that conversation that we were on our way to Sprint 1.  However, as we know, things are usually not that simple.  There were several more obstacles to work through.

(As an aside, I know that some people reading this might be thinking “what about Sprint Zero”.  These guys were talking about Sprint Zero, -1, -2…basically all the way back to Waterfall.  I needed to help them overcome that tendency.)

Below are a few of the other obstacles they were struggling with:

1. The program manager had assigned a project manager, one of his direct reports, as the ScrumMaster to the new Scrum team.  This person was already responsible for (and overwhelmed by) the Waterfall death march project now in perpetual change request mode.

Advice for anyone in this situation:

Find someone else to be the ScrumMaster.  It would be a better use of the external consultant (myself in this case) to serve as an interim ScrumMaster (coach) so that the team could just start, rather than trying to use a traditional project manager who was already overwhelmed by other responsibilities.  In other words, don’t wait for your ideal ScrumMaster candidate to be ready.  In most cases, management’s first choice for ScrumMaster is often not the best one.  If you do not have an experienced coach to serve as interim ScrumMaster, then the best thing to do is hire someone specifically for this role.  Again, it is better to just start than to wait for this new hire.  If you have to wait for the new hire, someone from the team should just volunteer and learn on the job until help arrives.  Even that will give you far better results than waiting.  Just start!

2.  The project manager who was assigned as the ScrumMaster was assigning Product Owner responsibilities to a business analyst that reported to him.  The “BA” was worried that the Product Backlog was not ready for the team.  The real Product Owner had created a high-level Backlog with items that were most likely too large for the team to complete within the two-week Sprint duration that they had decided on.  The BA was trying to work with the PO, but there wasn’t much reciprocity there, mainly because of lack of knowledge of the business on the part of the BA and the PO’s lack of trust in the BA’s ability to serve as his proxy on the team.  During one of my previous visits over a month before, the PO, BA and a few of the other team members had workshopped the Product Backlog, refining the top “epic” and creating a User Story small enough for the team to start working on and complete in the first Sprint.  Now, that story was lost and forgotten.

Advice for anyone in this situation:

Don’t wait for the Product Backlog to be perfect.  If the Backlog is not ready, use the first part of the planning meeting to identify what the team and the Product Owner can agree on as the deliverable for the first Sprint.  In fact, that is all you should be discussing in this meeting in any case.  With the right people in the room (the whole team) this can be done well enough.  If the team is not able to agree within the time box of this meeting, it most likely means that you don’t have the right people in the room.  For example, there may be a project manager and a BA who want to delay the start of the project because they feel uncomfortable with the perceived ambiguity of the process.  It would be better if these people were not on the team and not in the room.  If the team says something like “we can give you ‘X’ in two weeks” and the Product Owner says something like “good with me”, then make that your Goal for the Sprint and get on with the second part of planning—creating a set of tasks to execute the deliverable.

During the first Sprint, the Product Owner can be working with the team to refine the next items in the Backlog based on what has been learned from the Planning Meeting, which is probably a great deal.  The purpose of the Product Backlog is to realize a great Product.  Don’t wait for a perfect Backlog—just start!

3.  The culture of fear and distrust perpetuated by IT management was pervasive and the team was afraid to make a commitment to a deliverable.

Advice for anyone in this situation

Help people understand commitment as a team capability that develops over time.  Teams are able to make and keep commitments based on historical velocity.  For at least the first Sprint and perhaps for a while after that, new teams will not be able to make firm commitments.  Most teams fail to deliver after their first Sprint.  There is a learning curve to Scrum.  There is a lot of change and a lot of new things going on.  The environment of a new Scrum team is drastically more dynamic and complex than what most people have previously experienced.  It takes getting used to.  People need space to learn.  Help them overcome their fear of failure.  Agile is about failing fast.  Get it wrong early, learn, adapt and change course.  What a young team needs to be committed to is learning what it needs to do in order to deliver potentially shippable product every Sprint.  In order to do that, you need to be doing Scrum.

I started this post by identifying that there are many reasons to delay “doing” Agile. I believe this stems from a cultural dichotomy in our society between “being” and “doing”.  We don’t start doing something until we believe that we are prepared to succeed at it.  We have to “be” ready before we can “do”.  This is a false dichotomy that Agile is designed to help us overcome.  Another dichotomy is success vs. failure.  The only real failure in Agile is the failure to learn and improve.  Even the notion of “failure to deliver” is misguided.  The real failure is not learning to deliver.  In order to “be” Agile, you need to be able to fail.  In order to “fail” at Agile, you need to do it.  By doing Agile and failing, we learn to be Agile.  There is no other way.

So, please… just start!

 


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Article Summarizing Scrum from a Management Perspective

Learn more about transforming people, process and culture with the Real Agility Program

I always love the articles written by Glen Wang, one of my former students.  He has written another good one called “Manage Objectives, Actions, and Uncertainty in Scrum“.  I’ve added a bit of feedback because I think there are some important changes that need to be made to the article, but overall I love the concepts, information and presentation.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Announcement: The Scrum Team Assessment

Learn more about transforming people, process and culture with the Real Agility Program

Over the past six months we have been working hard on launching a new product: The Scrum Team Assessment.  This tool delivers to you a valuable report full of practical advice on how your team can get better at Scrum… and deliver better results!  It’s like an automated Scrum coach.  All your team members will fill in a comprehensive survey, we collect the results, generate a report – and then we personally review it – and send it back to you.

For more information, please visit our Scrum Team Assessment site.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Building Capabilities for High-Performance, Part 1

Learn more about transforming people, process and culture with the Real Agility Program

This is my first crack at a series of posts intended to document reflections, insights and experiences that have been generated over the past several years at Berteig Consulting in our work helping organizations to transform with Agile methods and approaches.

The most recent iteration of our collective practice is the Real Agility Program.  The Program was created as a flexible yet systematic process for developing high-performance teams.  The Program involves assessments, training, leadership and delivery teams coaching and internal coach development for teams and organizations that want to transform in order to become hyper-productive, lean and robust.

A central tenet of the Program is that teams are organic in nature.  They are living systems that grow and develop in the right conditions.  They also develop in stages.  The Real Agility Program addresses the natural stages of team development with a sequence of steps or “sections”.

Much like a seed, a new team has the latent potential for developing into a complex organic system of high-performance capabilities.  Capabilities of high-performance start out as a simple set of attributes and grow in complexity and strength over time.  Capabilities to carry out more complex activities are built onto capabilities for more simple activities.  Little by little, high-performance can be realized in this way.

Something that most teams need help with early on, particularly if they do not already possess a growth mindset, is overcoming the false dichotomy between theory and practice.  An indication of this is when we hear people say things like “well, that makes perfect sense in theory, but it’s just not practical for us.”  Or “we need help to put that theoretical idea into practice in our own reality”.  This reveals a mindset that conversations around concepts and ideas are only valuable if they can be implemented immediately in a measurably beneficial way.  The desire for technical recipes is understandable.  They can help with immediate pain relief.  They are not the most effective way to build capabilities.

The Tree of Organic Growth is an exercise that we often share early in the Program and is designed to help teams develop a more integrated mindset and approach to capacity building (very similar to The Tree of High-Performance in Lyssa Adkin’s wonderful book Coaching Agile Teams).  The facilitator usually starts by drawing a simple diagram of a whole tree, including the roots.  Sometimes, simply exploring the concept in a conversation serves the purpose just as well.  The team is asked to identify values, concepts, principles, qualities, skills, attitudes, habits and knowledge that are already present on the team that will serve as roots for building capabilities of high performance.  The conversation is not merely a nice, (“fluffy”) theoretical stroll in the proverbial park, but a critical aspect of the hard work of re-shaping thought, which in turn re-shapes reality.

Let’s look at an example of the aspects of building a specific capability.  A well-known Agile capability of high-performance is the self-organization of the team.  On one level, it starts to happen as soon as a group of people come together to accomplish something and no one person is identified as the “boss”.  Without certain capabilities in the members, however, this can get very Animal Farm in almost no time.  High-performance requires the development of qualities, attitudes, conceptual knowledge & understanding, habits and skills in all members of the team.  For example, team members need to develop the qualities of openness, integrity and helpfulness.  Attitudes such as a humble posture of learning and serving the team need to be developed.  Knowledge of concepts such as consultative decision-making and Wideband  Delphi and how self-organization differs from traditional command and control project management needs to be developed.  Good habits and practices such as regularly coming together as a team to reflect and plan are essential for the team to become able to deliver complete increments of high value often.  And, of course, team members will need to learn skills in terms of communication and collaboration, as well as other technical skills that may have previously been outside of their formal roles.

Furthermore, everyone can develop in any of these areas of any capability at any given time.  Just like in any organic system, capabilities of high-performance benefit from constant nourishment, feedback and reinforcement.

Growing a high-performance team is a complex process that requires a great deal of effort, patience, time and a supportive organizational environment that will allow for all of these aspects to develop on a team.  It is an investment in people as much as it is a business decision.  There are no shortcuts or formulas, but with the right conditions, every team has the potential to develop capabilities of high-performance.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail