Saturday, December 13, 2014

What is the Agile Way to Adopt Agile?

 just posted an interesting question on the Stoos linkedin group. "What is the agile way to adopt agile?" Her answer did not resonate much with me, so I'd like to share I start a company down the agile path.

Agile is about people, both the people doing the work ("People and Interactions over Process and Tools") and the beneficiaries of the work ("Our highest priority is to satisfy the customer through early and continuous delivery...."). I believe people's own experience makes the most convincing arguments.

So I start by asking the people involved what has worked for them in the past. I ask them to remember their best projects and share the stories of those projects with other people in the room. (See Remembering Heaven for a description of how I do it). After hearing everyone's best projects and identifying the most promising role models for moving forward, we reflect on the patterns that made those projects successful.

Most people are not currently working on their best project ever. In fact, usually only about 10% of the people in the room are currently working on a great project. Very often no one at all is currently working on their best project ever. (I have seen numbers as high as 50%, but the difference between 10% and the higher score has always been a group doing Scrum!)

Would you like to be working now on your best project ever? Most people would! Could you agree to implement the patterns which made your best projects so awesome? Most people are willing to do that.

Wait! What exactly have we agreed to? Well at this point, I start to introduce Scrum (my favorite place to start), not as a set a of roles and processes, but rather as a small set of patterns. These patterns are easy to recognize in people's own successful projects. What patterns do we find?

  • Deliver something that works regularly
  • Inspect and Adapt regularly
  • A small interdisciplinary team solves the problem
  • Once voice speaks for the customer / user / stakeholders
  • High performance is achieved through continuous improvement 

So now agreeing to do Scrum is quite easy, and we can start without any significant resistance. Why?People recognize Scrum as a place they want to be, because it is a place they have already visited and liked: A great project where work is fun.





Wednesday, September 24, 2014

Tackle your organization impediments with 59 minute sprints!

As a comment on "How much do you let a new team self organize?" IanJ asked
Why are 59-Minute Scrums cool and what are they good for?
The 59 Minute Scrum has been a popular training exercise for years in the Scrum community. The team gets a problem to solve, and goes through a "simulated" sprint to solve the problem. You get to experience real Scrum in a safe environment.

Fifty-nine minute sprints are an excellent learning tool because so much happens in such a short time. Everything that goes wrong in a real sprint can happen in a 59-minute sprint.  They are great for problem solving!

In my classes, I usually simulate a 3-day sprint, using 5 minutes for each half of the Sprint Planning and the Sprint Review, 12 minutes for each day, and 4 minutes for each daily scrum. If you add it up, it comes to 59 minutes. Each Scrum Team has a Scrum Master, a Development Team and a Task Board. Depending on the context, there may be one Product Owner for all the teams in the room, or each team gets it's own PO. Note the 59 minutes does not include the Retrospective, which I handle separately in my courses. I usually don't too much about the length of the Sprint Review either.

I have found that if a team does three of these over three days, by the end of third iteration, they are really good at the basics of Scrum and ready to do it "in real life."

What is the difference between this being a Scrum simulation and a real-life "micro Sprint"? Well not much, except for the importance of the results you are producing. If you plan to throw away the results, it's a simulation. If plan to use them, it's a micro-sprint.

What would be an example of using micro-sprints? One area is to address organizational impediments. Imagine you have assembled in one room not just the Development Team, but also their management, important stakeholders, the operations group and other interested parties for the product. Ask them, "What are the biggest impediments to success of our project?" Have them write them on stickies and post them on the wall. Like in a retrospective, have their owners present them. The others can ask clarifying questions.

Finally you do some sort of dot-voting to identify the top issues. Exactly how you do this depends on many things, most importantly the number of people in the room. One way is to each table create a short list of two or three items, merge the lists to get about 10 to 15 items, then have everyone dot vote the this short list to prioritize the problems.

Now you are ready to use Scrum 59's to tackle your challenges. What could you do to solve the issues identified? Form teams around the top priority cards, usually one team per card and one team per table (did I mention, island seating with about 6 to 8 people per group?) Whoever wrote the top priority cards becomes Product Owner for those cards.

Iterate once or twice to come up with possible solutions for those impediments.

I have seen awesome results with this approach! Usually the people who are most surprised are the managers in the room, because they have never seen their staff working so creatively and with such energy. And the teams come up with good ideas that the managers never would have thought of. Oh, and they get really good at the mechanics of Scrum and ready to take on the challenges of their project using Scrum to help them.

Prepare to be amazed! And don't forget you can start implementing those solutions right away!

On the road to high performance teams

I have been thinking about continuing education for Scrum Masters.

The objective of a Scrum Master is to create a high performance team, which is in turn part of a high performance organization. So both team and Scrum Master must develop their skills moving forward. Just facilitating the Scrum meetings won't get you there.

The Scrum Alliance has defined the Certified Scrum Professional (CSP) program. This is the journeyman-level Scrum certification (think Apprentice -- Journeyman -- Master ). This certification is not achieved by passing a test, but rather by demonstrating a commitment to Scrum by doing Scrum and learning about Scrum.

How do you achieve the continuing education needed to achieve journeyman status? My answer is the Scrum Breakfast Club. The Scrum Breakfast Club is an inexpensive, recurring open-space format for solving problems related to Scrum and Scrum Projects (and learning advanced Scrum as you do). You bring your problems and find solutions, with me and with other people who face similar challenges. I also provide an opportunity for one-on-one coaching during this time.

Each Scrum Breakfast Club workshop earns you four Scrum Education Units. (If you are familiar with the PMI, these are like PDUs, and can also be used as PDUs).

From a career point of view, if you take a CSM Certified Scrum Master course, follow it up with a CSPO Certified Scrum Product Owner course 6 months later, and participate regularly in the Breakfast Club, after 2 years, you will have accumulated enough Scrum Education Units to qualify as a Certified Scrum Professional. And you have had plenty of opportunities to address the actual issues in your organization.

Here is a description of the Scrum Breakfast Club. How does this fit into your plans?

Monday, September 15, 2014

Getting Starting on #POcampCH -- the Product Owner Camp Switzerland

Today, the organization team for the first Product Owner Camp in Switzerland, held its first telco. Here is what we decided:
  1. Our target date is March 2015, the alternative is June, 2015.
  2. The open space will be held on a Friday and Saturday.
  3. We want to hold a Product Owner Masterclass, one or two days before the Open Space event.
  4. The audience is experienced Product Owners, Agile Product Managers and Lean Startup Practitioners. This is by practitioners for practitioners, not for beginners.
  5. The event is not profit oriented. 
  6. We are going to get together on skype roughly once every to two weeks to take the event forward. 
We are thinking hotel in the mountains, we will start exploring possibilities once the constraints for the workshop are defined. 

We have created a backlog to organize our work: Our first objective is the find a leader for the MasterClass, reserve some dates, and start working on the website. After that, priority will be the venue...


Several other people expressed an interest in helping to organize, we will welcome them as they confirm their participation :-)!

Are you interested in participating (or even helping out?) Join our google group to stay informed!

How much do you let a new team self organize?


I have a team of 11 developers and 3 Product Owners. Their ideas about how to organize the team are all over the place. Some want to do 1 week sprints. Others want one month sprints. And we pull in resources people so we can get the right velocity to meet our deadlines. This seems like a mess. How much should I let my beginning team self-organize? -- recently asked on a Scrum Discussion Forum.    
Modifying a complex technique before you have mastered it is a failure pattern. So when you are just getting started, try to get as close to Scrum by the book as you can, without obsessing over it... much. I call this Pretty Good Scrum(tm). ;-)

Yes the team self-organizes... and the Scrum Master is charged with teaching the team and helping them improve. When the team is just getting started, it should follow the lead the of Scrum Master, and the Scrum Master should stay close to the book. As they get better, they'll be better able to inspect and adapt themselves.

Successful teams learn quickly. How do you learn quickly? Short answer: Do short sprints. More in a moment.

Remember, never hit anyone with the book! The rules of Scrum are there to help you, not to threaten or punish people. Be sure you can answer why the rule of Scrum is a good answer. Treat everything as an experiment or learning exercise, so they have the security of knowing they can change things later. That's what retrospectives are for.

It will probably take you three or four sprints to get to Pretty Good Scrum. That's why I recommend one week sprints to start. Why learn in four months what you can learn in 4 weeks?

If I were confronted with the situation above, I would ask five questions and help the team(s) and PO(s) find answers that stay within the constraints defined by Scrum.

1. How big is a Scrum team? 7+/-2. To stay in those bounds, you need two teams. Ask your teams how they want divide themselves, respecting that constraint. By giving them the problem, they become responsible for the solution, so they won't come to you anymore with "yes, but..."! If they talk about limited specialists, ask them how to resolve the problem.

2. How many Product Owners does a Scrum Team have? One, though you might also have a Chief Product Owner role in the case of multiple teams. Ask your product owners how they want to split up their work. And yes, the PO is responsible for the Vision. Do they have one, can they communicate it? Is it shared and supported by the Team and other stakeholders?

3. How long is the Sprint? Normally this is negotiated between PO and Team. And... as Scrum Master you are responsible for the process, which gives you the right to intervene to improve the team. Shorter sprints accelerate learning. So I would suggest starting with a couple of one week sprints. Be sure to get your team to agree to this. I have also had great experiences doing 2 or 3 sprints at 59 minutes each (ask me more about this if you're interested).

4. Who estimates and decides how much work can be accomplished in a sprint? The team. Not the math, not the PO, not the stakeholders and not management. Have them estimate the work, and don't let them take on more than they can chew. Think of highways at rush hour if you want to know why this is a good idea.

5. Whose job is it to make sure that wish and reality are in harmony with each other? The Product Owner. If the desired scope does not match up with the team's reasonable forecast of what they can accomplish by the desired release date (aka deadline), whose job is it to fix the problem? The PO. Given your context, conversations about reducing scope and the impact of product-level multitasking on ROI might be quite fruitful!

Back to the original question: "How much do you let a new team self organize?" The answer is "quite a lot!" The trick is setting constraints that cause people to come up with right answers.

Friday, September 12, 2014

Pair & Share - a simple technique for Sprint Planning

How do you get the team to plan tasks effectively?
The second half of sprint planning is often a challenge for teams starting Scrum. It used to be their Project Leader would do the planning for them. Now the team has to figure it out for themselves! (Doesn't the Scrum Master do that? No!) How can you as a Scrum Master encourage your team to plan the Sprint effectively?

Many teams have difficulties doing task planning before they have thought about the technical concept. To address this challenge, I have a strategy I call "Pair and Share".

Preparation

Good preparation is half the battle. This means that coming out of Sprint Planning 1, you should have a selected product backlog ("forecast") that consists of reasonably small stories. Six to 10 items in the forecast is a sign that the stories were small enough (assuming it is a good forecast).

Your team has had the conversations with the Product Owner, the Stakeholders, other Subject Matter experts, etc, and the confirmation is reasonably clear, perhaps in the form of a how-to-demo workflow, or other criteria which can be readily turned into an (automated) acceptance test. If you are still discussing the confirmation during the task planning, you probably have a long meeting in front of you ;-) Having said that, there is a reason the Product Owner should be in the room!

Pair and Share

Here's how it works:

As a Scrum Master, I would take a moment to remind the team about the importance of working according to priority, getting things really done (as opposed to getting a lot of stuff sort of but not really done), and of minimizing work in progress, especially unfinished work at the end of the sprint. The goal for this meeting is not to create the definitive technical concept or task planning, but to create enough of each that the team can start working.

Then timebox Sprint Planning 2, the second half of the meeting, to one hour per week of sprint. So for two weeks, that gives you two hours. Divide that again in two halves, in this case 1 hour each for conceptual work and for task planning.

Have the team pair off. So if you have 6 people in the team, you have 3 pairs. Each pair takes two or three stories (what does this say about how big the stories are?). They have 1/2 hour to come up with their initial technical concept for implementing each story. So they timebox their discussion to 10 or 15 minutes per story.

After the first half hour is up, each pair explains how they want to implement each story to the rest of the team. Short Q&A. You are probably timeboxing the presentation to about 5 minutes per story. The rest of the team can ask questions, so this "share" part builds shared understanding and serves as an initial design review. The discussion may cause the team to rethink their solution, which will influence the task planning.

So now an hour has gone by, and you repeat the process, this time for task planning. Split into pairs (possibly different pairs than the first time), take the top stories, and do 1/2 hour of task planning.

During the final half hour, the team meets in front of the task board. One by one, each pair posts and explains their task planning to the rest of the team.

So now, pairs have thought relatively deeply both about the technical concept and the task planning. The whole team is consulted, and the team is well positioned to work forward as a team to start implementing.

BTW 1 - It may be that the team wants to think more about a particular item before committing to that particular concept. That's OK! Just make a task, "Finalize Design" or whatever.

BTW 2 - How did I come up with this? One of my first teams asked themselves this very question, and this is what they came up with! It worked beautifully! So if this doesn't feel right for your team, give them the goals for the meeting and ask them how they want to do it! Maybe you should even do that first!

Tuesday, September 2, 2014

Frameworks considered helpful

Jurgen Appelo recently wrote:

I know of no industry in the world that is as infested with methods and frameworks as the software business. Whether it’s RUP, XP, Scrum, AUP, DAD, or SAFe, it seems IT businesses are always looking for yet another method or framework that they can “implement” next month.

As a retailer, how often do you come into contact with filmmaking? Not very often. How often do you come into contact with road building? Except when you are stuck in traffic due to a construction site, not very often.

How often do you come into contact with IT? Every business comes in contact with IT. Whether to sell on online, automate processes, manage work, or whatever, every IT and software are everywhere. And IT projects can be extremely complex and failure is quite common.

And IT is so widespread, there aren't enough experts to go around -- or why does Jurgen tour the world to promote his book and his framework, instead of working with individual companies to help them improve?

Most people have no idea where to begin. Our instincts from our hunter-gatherer phases evolution are often counter-productive. So frameworks are essential. They are reasonably well understood place to start. Some of them even work pretty well, like Scrum (or even Kanban ;-) if you apply them reasonable well. And this is hard part.

For some more research-driven explanations as to why frameworks are helpful, see Chip and Dan Heath's book: Switch, or How to Change when Change is Hard. Their example on Minimally Invasive Cardiac Surgery is particularly illuminating. Taking on a new complex activity requires a good place to start, a lot of practice, and a willingness to learn.