Lean Product Management at SDEC13 in Winnipeg

/by

In October, I will talk at the Software Development and Evolution Conference (SDEC) 2013. It’s an annual conference where industry professionals share their own real-world experiences gained through delivering solutions and my talk will be on Lean Product Management.

The rise of the Lean Startup has led to a deeper understanding of the importance of validating business ideas, from new features to new business models. But many tools available to the Product Owner aren’t adapted to rapid validation. Starting from the principles and practices of agile product management, from defining the product vision to creating story maps and refining the product backlog, you will learn about key practices that incorporate the lean startup principles, allowing a Product Owner to bring the build-measure-learn cycle alive and ultimately earn more value more quickly.

Registration is now open if you wish to see me live! Slides and materials will of course be featured on this blog as well.

A question and exclamation mark of jigsaw puzzle pieces

Listen, be curious and ask the great questions!

/by

Working as a ScrumMaster or Agile Coach for a team, you know that one of your most important objectives is to help people better themselves. “Ask the team” we often hear, but actually, our job is a bit more complicated than that. Asking the right questions can be a challenging task, especially if you already have the “right” answer in mind. If this sounds familiar to you, there is help in the curriculum of professional coaches.

 

The first important ability you have to learn is to be silent and listen. When coaching individuals and teams, you are not the important part. They are! Therefore, active listening and awareness of which level you are listening on, is essential. Professional coaches talk about three levels of listening:

Level one is your level if you are unaware of active listening. Here, you relate what is being said to your own world, situations your past recall, your strong opinions about the matter and so on. Most likely, you end up being the one talking, sharing your own experiences and giving advice. Is this helpful for the person or team in front of you? It can be, but it might also be that you have been providing the right solution to the wrong problem! When it comes to helping the one in front of you, to better their own capabilities, you definitely did not succeed.

When you are on level two, you are focused on the person or team in front of you. You are connected by eye contact, deep listening to what each person is saying and what the person is saying “between the lines”. You are trying to understand the perspectives and intentions of this person by letting yourself see the world from their position.

At level three, you are doing the same as on level two, however, you are also sensing the feelings; the happiness, frustration, the sadness of the one in front of you – and you reflect those feelings back.

When you are listening, it is almost impossible not to be at level one once in a while. It is not bad to be at level one, but you should try to find survival techniques to move you from level one to level two or three when you realize that you are on level one.

So what are we listening for?

One technique to apply is to be listening for keywords. Keywords are words that stick out in the conversation – words with a deeper meaning. When identifying keywords, you can repeat them to yourself to memorize them and use them to form new questions. In that way, keywords help to unlock the understanding of the topic you currently are discussing.

When using keywords, do not take anything for granted. Be curious about the obvious things and ask clarifying and verifying questions.

If you are in doubt whether a certain keyword is important or not, there is a simple and efficient way to find out. Just ask if it is important or not. You will get an immediate answer.

With the use of the levels of listening and asking questions based on keywords, you are on your way to being acting more as a coach than a mentor. There are of course more advanced techniques that you can learn but start by practicing these basic techniques before going further.

It is important to remember that not every conversation is suited for coaching. If you have a fixed agenda with the purpose of providing tough feedback, coaching is not the format to use. Coaching is for well-functioning people, who want to reflect on a matter and find new ways to act with the purpose of improving their situation. As a coach, you do not take the one in front of you to places that they do not want to go. A coaching conversation is a conversation, that you design together as a shared responsibility.

By the end of each coaching conversation, remember to ask for feedback so you can learn and improve. What did you do during the conversation that was especially useful? What did you do that was not so useful? Which questions did you forget to ask?

If you are interested in learning more about professional coaching in the context of agile teams, you can get extended agile education through the Advanced Agile Team Coaching course developed by agile42. Through this course, you will, in addition to acquiring professional coaching skills, learn about the Coaching Structure and tools that are part of our Team Coaching Framework and used on daily basis by agile42 coaches.

Read the second part of the series, “Your Strategy for Asking Powerful Questions”.

Photo by Horia Varlan, on Flickr

Cynefin Lego Game at Agile2013

/by

Our coaches Brad Swanson and Dave Sharrock are in Nashville at Agile2013 where they will present a workshop on August 8th titled The Cynefin Lego Game: Recognizing the Complexity Domain of your Problem.

The Cynefin Lego Game is a game to let you experience four of the five domains of Dave Snowden’s Cynefin framework and part of agile42’s management training for the Agile Management Framework.

From Dave and Brad workshop presentation:

We expect leadership teams to find innovative solutions to business challenges, and yet rarely give any consideration to how to solve these challenges. Current thinking is leading us to understand that different types of problems lie in different complexity domains, and require different ways of solving them. And the mix of solution types is shifting, meaning our traditional approaches to problem solving are not always suited to the new problems we encounter.

The Cynefin framework, introduced by Dave Snowdon, provides a simple model to understand the types of problems and how to solve them. Using Cynefin and complexity thinking can accelerate organizational learning by recognizing the problem domain for a particular situation and knowing what class of solution is appropriate. Recognizing the complexity of a problem is a behavior that will enhance learning, and failing to recognize it may restrict learning within the community.

As managers and leaders, we need to understand what types of problems we encounter, and which tools and approaches are best in each case. Using a series of Lego exercises, participants will experience each problem domain, from simple to complicated to complex to chaotic, and emerge different approaches to problem solving in each domain. Some will work, some won’t. You will experience the importance of choosing the right approach for each problem domain, and what happens when we use the wrong approach to solve a problem.

Expect to understand what type of system you are dealing with by recognizing when practices stop working, and learn to decode what is happening in terms of organizational structures and communication in that specific system.

Further information can be checked on our Cynefin Lego Game page: the game is licensed under the Creative Commons Attribution-Share Alike 3.0 Germany License and therefore can be played freely! Please let us know your comments and experiences.

Reading on a beach

agile42 Summer Reading List 2013

/by

Summer is upon us, at least in the northern hemisphere (and if you’re living in the southern part of the world, you shouldn’t complain either), and we have decided to use our community newsletter for something different. Even for Agile practitioners, there is vacation time, not only for relaxing with loved ones but also for keeping up with new thoughts and ideas.

We have therefore asked our coaches to help us compile a “summer reading list” of titles that would be appropriate in an agilista’s bag while heading for the beach or a solitary retreat (or even a city escape)! This eclectic list reflects the different approaches of a complex profile like the one shared by our coaches: we have heavily technical books, communication techniques and a sizeable selection of economic and military history. You can rule by yourself if their recommendations meet your style (most links point to the book page on Goodreads, where you can check details or obtain the title through your favorite bookseller).

Communication and coaching

Andrea Tomasini, agile42 founder and strategic coach, starts with our most obvious suggestion: What We Say Matters: Practicing Nonviolent Communication by Judith Hanson Lasater & Ike Lasater is a book all coaches have decided to read and practice in our everyday activities inside and outside the company.

Paolo Perrotta explains his choice for Facilitator’s Guide to Participatory Decision-Making by Sam Kaner:

At times, it reads a bit like a patterns book for facilitators. Useful to stick a name onto facilitation techniques. It is a large format, has not much text density, and is easy to browse through. A bit dry at first glance, sometimes disturbingly close to a textbook or a slide deck – but it more than makes up for that by focusing on a traditionally fluffy, “soft skill”-related subject and grounding it in clearly defined, pragmatic advice. The kind of book that makes me go from: “Oh, facilitation – I can do that” to: “I didn’t realize how much I suck at this”, and hopefully from there to: “OK, now I know how to do it right”.

Gitte Klitgaard Hansen adds The Go-Giver: A Little Story About a Powerful Business Idea by Bob Burg & John David Mann: “a book about giving in all that you do… Business and private…”

On Business

A few books take a different approach to the business world and organizations.

Ralf Kruse suggested Peak: How Great Companies Get Their Mojo from Maslow by Chip Conley with these words:

a great book on motivation, relationships and satisfaction. The book puts the needs of employees, customers and investors in the context of a simplified Maslov pyramid, which is, from my perspective, a great view of the needs and helps to reflect what is important in this relationship to motivate and make the difference. Chip describes the topic mainly through stories based on his experience leading, developing, creating and managing the boutique hotel Joie de Vivre. The stories help to give the topic concrete insights, and stories from non-software help me get new insights from this different perspective. It was in my bag last summer, and this makes it my recommendation for the summer reading list.

Niels Verdonk recommends The Goal: A Process of Ongoing Improvement by Eliyahu M. Goldratt and The Five Dysfunctions of a Team: A Leadership Fable by Patrick Lencioni. “Since they are both written in the form of a Novel, I think they make great beach or poolside reading.”

Martin von Weissenberg’s holiday book is The Company: A Short History of a Revolutionary Idea by John Micklethwait and Adrian Woolridge:

The authors argue quite successfully that the limited liability company is the most influential idea of modern times, and I think this book serves as a good reminder of why and how people organize themselves and find resources to carry out even large enterprises. Also, the book is quite entertaining and small enough to fit in a beach bag.

Manny Segarra also suggests Leading Change, John Kotter’s eight-step process for managing change.

Learning From the Military

Throughout history, any standing Army has always been one of the biggest and most complex organizations seen in action. It’s no surprise that Management Change looks at the military world as a source of discussion and ideas.

Ralf Kruse suggests Turn The Ship Around!: How to Create Leadership at Every Level by David Marquet stating “I think it is a great reading. The approach is quite similar to our, written from first hand experience and commanding a submarine is a different angle of view than product/software development.”

Our Kanban professional Gaetano Mazzanti instead suggests a title popular in the Lean community The Art of Action: How Leaders Close the Gaps between Plans, Actions and Results by Stephen Bungay, another book about the parallels between military and business strategy/tactics:

It starts with Bungay’s studies of the Prussian army in the 19th century. I liked the first part a lot (explaining the “problem,” which is the gap between plans, action and results). I am a bit concerned about the solutions he is proposing, but it’s still too early to tell. Definitely worth reading I would say anyway.

And Lasse Ziegler also recommends Corps Business: The 30 Management Principles of the U.S. Marines by David H. Freedman.

Agile and Technology

Let’s not forget our roots…

Bent Myllerup recently finished The people’s Scrum: Agile Ideas for Revolutionary Transformation by Tobias Mayer: “I do not agree with Tobias on everything he writes in this book, but I have a lot of respect for him and find this book important in the sense of being agile. It is a must read.”

And we should add our own, free to download, contribution: written by Andrea Tomasini and Martin Kearns, Agile Transition: What You Need to Know Before Starting is our first ebook for the agile42 community.

Written by the agile coaches of agile42, Agile Transition shares some fundamental knowledge to support many of the observations and conclusions that the authors have identified within organizations that have transitioned to a more agile approach to work. The authors share their failures and learnings in organizations transitioning to embrace agile, and they share their experiences of what is required to succeed.

In terms of solid technology tools, Stefano Rago recommends The Cucumber Book: Behaviour-Driven Development for Testers and Developers, “much more than just an introduction to TDD with Cucumber, it left me with an open, pragmatic and fresh mindset. This book inspired a lot of the best practices and approaches that form the foundation for my team’s work.”

And to top it all up, Roberto Bettazzoni suggests a solid video presentation by Ian Cooper: “TDD, where did it all go wrong,” freely available from Vimeo. Watch it with a glass of your favorite, and enjoy your summer!

Photo by Damian Gadal – http://flic.kr/p/a78Sau

stainless steel tool on gray sand

Kanban and Scrum

/by

In August last year Gartner signalled the death knell of Waterfall. All the evidence over the last 25 years points to some form of Lean-Agile method as the only sensible way forward for managing knowledge work. Kanban and Scrum (together with eXtreme Programming) are the pre-eminent Lean-Agile methods. I would argue that any investment you make in learning these will be the best investment you can make for your career and also the best investment your organisation can make in ensuring business sustainability in the long-term.

You might think it strange that a company named Scrum Sense would talk about Kanban. The truth is that Kanban was a baby in diapers when Scrum Sense started, while Scrum was already the de facto standard in the Agile world. When Maritza van den Heuvel approached me in November 2009 about the possibility of hosting David Anderson in Cape Town I jumped at the opportunity. He visited early in 2010 and we had a great time exploring this new process with him. We learned a lot and I’m tempted to say that we also helped clear up some mis-conceptions about Scrum.

Three years have passed and Kanban now has a significant presence in the Lean-Agile world. The latest worldwide Agile survey places Scrum and Scrum hybrids (most commonly Scrum + XP) first with 66% of the Agile market and Kanban second with 24%. Impressive growth in just about 5 years. Why is this?

As usual, there are some good and some bad reasons. Let’s start with the bad. Many organisations that attempt to ‘do’ Scrum are not actually willing to make the adjustments to their ways of working, ways of managing and company culture that are needed to realise the hoped-for benefits. Scrum is not the silver bullet they hoped for. So some look for the next shiny thing…and discover Kanban. By now, a number of these organisations have also dumped Kanban in search of something easier. One client of mine who did this has largely gone back to Scrum.

There are good reasons too. I see organisations trying to use Scrum to manage work that is really not complex, sometimes repetitive and whose arrival rate is highly variable. Not conducive to being planned in week- to month-long fixed increments. Much more suited to being handled using clear policies and SLA’s.

By now you are asking yourself what the differences are between these to Lean-Agile methods, and where to use what. This is, naturally, a non-trivial question. A good starting point to seek answers is Henrik Kniberg and Mattias Skarin’s free mini-book.

My message is this: if you want to be equipped to make good decisions in the future Lean-Agile world you need to educate yourself in both Scrum and Kanban. And along the way you will realise that you need to develop your so-called “soft” skills and learn how to manage organisational change too.

Growing powerful agile teams

/by

Agile teams are the building block to any successful agile transformation. Without strong, self-sustaining agile teams, any change as a result of an agile transformation is very likely temporary. At agile42 we spend a lot of time helping our clients form powerful agile teams, and in the following we explain a little about our approach.

Characteristics of an agile team?

As well as small, 6-9 people, an agile team is: 

  • Cross-functional – the team includes all roles necessary to deliver the work (at minimum Dev and QA), and dependencies outside the team (e.g. UX) are understood and available as needed 
  • Dedicated – team members are dedicated, with any non-sprint work transparently tracked on the task board and the potential impact (decreased priority) agreed with non-sprint stakeholders
  • Co-located (preferably) – defined as sitting in the same space. Where distributed teams are necessary, ensure strong ties are created through virtual tooling and regular communication
  • Working from a single backlog – the team has a single product backlog, containing items prioritized by the business and ready for the team to work on, from which to pull work
  • Managing unplanned work – agree with the PO an agreed contingency or bug capacity to be removed from the sprint; manage this contingency to avoid impacting the sprint commitment

Getting started

We start with a conversation with the team around the +15TEAM assessment, a simple dashboard of 15 basic agile behaviors and practices that provide the foundation for an agile team. The +15TEAM acts as a seed for discussion and understanding about why each practice is part of the foundation of a successful team. 

But the +15TEAM is not enough. We need a team to develop new habits and skills, and to break old destructive habits. Any new agile team will pass through three levels of growth to become high-performing, predictable agile teams. 

Three stages of an agile team

Stage 1 – Predictable Delivery

Start by creating a habit of finishing work requests within the team. Many teams or developers working in a traditional environment quickly lose the habit of finishing a feature completely, perhaps as a result of silo’d delivery or high interruption levels. Quickly reintroduce this habit, before focussing on other agile behaviors. Without the habit of getting to done, a team will never progress.

Predictability is the ratio of the number of story points completed to the number of story points committed to. High predictability is above 90%, the target above 95%. Completing a story means meeting all the points mentioned in the Definition of Done, defined by the team itself.

Stage 2 – Build Quality In

Once a team has the habit of predictable delivery, the team turns their attention to quality. While learning to deliver predictably, the team has become more and more aware of technical ownership. 

With support from the business and the product owner the team have already taken on non-product related stories to improve their working environment or remove technical debt. Focusing on the technical standards the team works to, they raise the bar and build quality into their process. 

Tightening the Definition of Done constraints or measuring and making visible quality metrics and technical debt, such as bug counts and the results of static code analysis, contributes to a focus on quality, and in particular, building quality into a product, rather than chasing quality at the end. 

Stage 3 – Sustainable Delivery

Finally, once a team has mastered completing the stories they commit to while building quality in, they turn their attention to improving throughput. This is a delicate step because a traditional mindset might set velocity goals to increase productivity. But velocity is a lagging indicator, telling a team after they have reached a sustainable pace, rather than a leading indicator telling the team what more needs to be done. 

Think of velocity like weight. I can measure my body weight to determine how much I weigh today, but on its own my weight cannot tell me how my weight will change, whatever I promise to do.

Instead focus, through observation and frequent retrospectives, on aspects of the technical environment or team dynamics that prevent high performance. This might mean speeding up feedback loops for the development team through continuous integration and test automation, or using the retrospectives to enhance team work around a single story. 

Remember enhancements on productivity often have a negative impact on the predictability of the team. For example, challenging teams to take on additional stories to expose weaknesses in their development environments or team dynamic, means predictability will fall as stories are dropped. Set expectations appropriately, and make the work of the team transparent, to help mitigate concerns raised by variations in productivity.

In closing, growing powerful teams takes dedicated time and targeted effort. Changing team behaviors and practices requires the courage to recognize mistakes, and the honesty to delve into the root cause of the results, good and bad, the team delivers. But the rewards are impressive: A team that stands on its own, robustly handling organizational churn, and with the capability of predictable delivery of new features. Think about it – it might be worth it.