May 17

Taking agile to the rest of the business – what your existing agile deployment can tell them

According to GOV.UK it takes “at least three weeks” to get one’s passport renewed. If it takes two days to get there, two days to get back, what is it doing for the other 10 days? Background checks, watch-list checks, wanted-list checks, fraud-checks, depositing the cheque-checks are all electronic and cannot, surely, take 10 days. You can expedite your passport renewal and get it in 4 hours if you appear in person. What would it take for the passport office to adopt fours-hours for all applications? It would require that it become an agile enterprise. Note that, compared to the USA (4-6 weeks or 2-3 weeks expedited), Australia (3 weeks or 4 days expedited) and Canada (3 weeks or 1 to 10 days expedited), the UK Passport Office is doing very well.

 

Agile reduces the time taken to bring business ideas to reality. By putting the focus on smaller projects turned around in shorter timescales, agile is designed to get results quicker, delivering the priority needs in priority order, minimizing risk and improving quality. However, agile methodologies can be useful for improving functions across the business by helping teams focus on evolving their approach as other internal demands and/or market conditions change.

 

Rethinking internal IT

One of the main aims for agile is to keep pace with what the business requires and adjusting to the changing business world at the same cadence as the business must. Indeed IT makes it possible for the business to adjust to market conditions with a speed that has never before been possible. No longer can we deliver what the business said it needed six months ago and we can’t put any effort into something that ends up out of date before it’s completed. Establishing an agile development process speeds up the delivery of value back to the business and eliminates much unnecessary rework along the way.

 

This emphasis on creating results faster links into other areas of IT too. Where IT meets the users, in the service desk team, support staff who are more agile, more self-organizing, using a mix of tools, people skills and experience fluidly, discover that they have more freedom to concentrate on problem solving and customer satisfaction. This means empowering staff with more flexibility on how they approach problems and directing them to take ownership of users and their issues. In return IT gets more visibility into the changing landscape of the business and the ability to adjust real-time and plan ahead as trends emerge. Instead of annual reviews of data, IT should be reviewing data daily looking for trends and shifts in business behavior and thinking.

 

Adoption of agile across IT results in improvement in the overall processes and culture around service and support. There is better communication,  everyone has better visibility of what is going on and each participant has a sense of ownership in the outcome. This attention to business needs and velocity raises end-user satisfaction and leads to improvements in call resolution metrics.

 

As agile affects the development process calendaring and social tools get more widespread adoption and are seen useful across IT. But these tools also provide a place for all stakeholders, in IT and outside IT in the business, to collaborate together and track what is being delivered and when. For release planning this is critical in avoiding problems of dependencies and problems around availability across IT systems, personal and infrastructure.

 

In a jam? Just add agile!

This model of Agile IT can be taken into other areas of the business where the need to respond faster to requests is becoming a pressure point. For other business units, such as marketing, sales or operations, agile can be used as a way to re-think processes too.

 

Introducing agile to any non-IT department involves helping them see why the guiding principles of agile can be useful for their own projects. What’s not to like about a more joined-up approach across teams that helps deliver better quality work faster? It’s all about working out how to apply this in real life situations and building up a picture of what would work well for each team.

 

If agile software development focuses on matching the marketing rhythm; an agile marketing team should be looking to match the sales department’s tempo. An agile marketing team would be working on projects with their sales counterparts and other inside groups and maybe even outside agencies in a fast-paced, results-oriented, engaged manner. Taking a more agile and collaborative approach might involve some of the following:

 

  • Internal marketers and agency teams tracking competitors and correlating with sales team feedback from their customer interactions giving a 360° view of the market tracking trends, threats and opportunities in real-time. Doing so makes this part of a holistic campaign rather than a sequence of unrelated launch events pushed into the market blindly.
  • More collaboration across sales and marketing so that if a competitor launches a new product, then sales’ response and marketing offers can be co-ordinated rather than run as separate efforts.
  • As and when market changes occur, marketing can adjust not only the content but also the medium through its closer understanding of sales needs and market expectations. And it can do it today rather than sticking to what was planned six months ago.

 

All of this should mean the best possible outcome for the business. In practice, agile will be part of the mix that a marketing or sales function could bring in. There is still a requirement for a guiding vision that will be supported by planning, but this should fit alongside a more general approach that can react more quickly to market conditions.

 

When looking at agile in the business, a more joined-up approach across teams and driven by more orchestrated tools and processes makes sense. Most employees could tell a story on being asked to do something quickly by a colleague from another department who seemingly doesn’t understand how much effort that task really entails. Better visibility into the processes that go on behind the scenes will give teams more realistic expectations of when to expect work to be delivered and means they can plan ahead for it.

 

Agile’s benefits go beyond an improved project outcome. Done well, adopting it should create a more responsive business and happier staff who understand each other better. If individual agile business units work, think how effective connecting them up to form one single agile organization could be.

Permanent link to this article: http://agilethings.nl/taking-agile-to-the-rest-of-the-business-what-your-existing-agile-deployment-can-tell-them/

May 16

Kick them out

biteYears ago I attended my first ever Scrum course. I was to become a Scrummaster and in front of me was the insightful and powerful Jeff Sutherland. Everything he told us was grand and fantastic. I listened to everything he said and loved it. But there was one thing that kept me thinking for years. Someone in the audience asked what to do when some employees within the company are not willing to work with Scrum or, for that matter, change the way they do things. His simple, short and sharp answer was “kick them out”. Laughter and agreement from the questioner and the audience, and with that the question was done. But it kept me thinking. It is not that simple I always said from that moment on. And it is probably an American thing to just simply lay someone off who does not agree with your business decisions I thought and that in Europe we don’t do that. But is this true. Do we always have to bend to people within a company who simply don’t want to follow or adapt. I like people to lead but towards a better way of working and thinking, but that’s me. But in basic, you have set a new way of working within your company and it would be great when everybody can see the light en embrace it’s manners. But what to do with the few who won’t.

You can explain them why it would be a good idea. You can show them the way. Ask them to try in the hope that the virus will catch on. But in the end when you have tried everything and depleted all your coaching skill with the. And their behavior is even starting to crumble the freshly laid fundaments you are trying to build. In the end you just might have to let them go. Is that so bad or strange. I don’t think so. If you come to think of it. Incorporating Scrum is not that different from any other change within the company. The new rule that people no longer can wear shorts in the office will go without or a little argument. The fact that people are no longer allowed to park their car in front of the office but have to go across the street. Hey they may not like it but will understand. Even the fact that certain software is used or everybody works on an Apple or no smoking is allowed within the office is easily accepted. If people don’t want to follow those rules, they can leave. Not that crazy right. So why, if a company is willing to change for the better of the people and the process, it is not done to get rid of people who go against the flow. Who basically are trying to kill the framework and therefore possibly your company. Why is that all of a sudden tolerated. Yeah sure, Scrum is just a hype. But so was the internet, the bike and the car. We all know it takes time. But as with these last three examples and there are probably many more, Scrum is not a hype. It is a change. And one of the first that actually looks at how people think and interact. It’s a bit like biting the hand that feeds you. If it is bitten too hard, a punch in in order. If it is bitten repeatedly, it is back to vet. And if the dog is lucky, it is just its balls that are on the line. But don’t be gently. We are in the business to get things done and to be honest, earn money. Right. So act like you want to keep on doing that. This does not mean that you have a sort of shock and aw everyone like Jeff would like it. But you don’t have to be gently either. Take is seriously and tighten the reigns or you might end up with just a few tattered socks and an angry biting dog that won by leaving your company in shatters.

Permanent link to this article: http://agilethings.nl/kick-them-out/

Apr 30

Functional agility vs. technical solidity

10Scrum is about delivering value to the business right now and being agile when it comes to future wishes. Software architecture is about being prepared for the future. Those two don’t seem to match very well. Well, agile does not mean ignorant, and prepared does not mean ¨cast in concrete¨. So start doing, and never stop thinking!

 

Religion

It don’t think it was ever a conscious decision to not call myself an agile evangelist, but I was really happy with it anyway when I was talking with George last thursday. He said Scrum was both a blessing and and a curse for him. The curse was the fact that many people use it as an excuse to stop thinking about the future. They use Scrum as a religion, rather than as a tool.

I can relate to George’s frustration, but I personally have more experience with the opposite end of the spectrum: people who are unwilling (or unable) to build anything unless they are convinced it is the best solution, considering all current and future wishes they are aware of.

Both attitudes are serious problems. But hey, nothing a good retrospective can’t fix, right (or am I being too religious about that)?

Balance

But even if you have honest and open communication between both parties: what is the right balance in this apparent trade-off between functional agility and technical solidity? In my opinion there are two problems at hand:

1. Dealing with future wishes.

2. Ensuring good enterprise application integration.

Future wishes

Consider 2 stories: A and B. Story A must be delivered in the current sprint, and the related story B might have to be delivered in a future sprint. The next table shows the estimates for various technical solutions for these stories.

Solution X at first, solution Y later

Solution Y directly

Story A

100 manhours

120 manhours

Story B

200 manhours

120 manhours

As you can see, in the current sprint the team can choose to spend an extra 20 hours and possibly save 80 hours in the future. But if story B never makes it to a sprint, the 20 hours are lost. Simplifying the problem to this example makes it look like a gambling game, where you look at the stake, the likelihood and the prize, and then decide. Real life software development is rarely that simple. There usually also are related stories C, D, E and F, and then a bunch of things that nobody mentioned to the team or even thought of yet. Priorities will change and currently unknown details might require a solution Z that is much more work.

Am I saying that the team should only think about story A and choose the most straightforward solution for that? Not exactly. An important element of delivering high quality software, is building a solution that is likely to be stable. This is why most developers will refer to solution X as ¨quick and dirty¨. In the example of just stories A and B: in 9 out of 10 of the cases, spending the extra 20 hours for solution Y will result in better quality for story A in itself. In those cases it is best to just do that, regardless of the likelihood of story B.

Enterprise application integration

The second area where architecture principles and Scrum might conflict, is enterprise application integration. Scrum explicitly states that no one tells the development team how to turn product backlog into increments of potentially releasable functionality. How does this combine with the role and responsibilities of an enterprise architect, especially in an environment where the product is part of an integrated portfolio of products?

In my opinion, the freedom of the development team fully applies to the internal architecture of the product they’re developing. The team may consult the enterprise architect or other experts (and should do so certainly for expertises that are missing in the team), but in the end the internal ¨how¨ is the responsibility of the team itself.

When it comes to integration, the requirements that the product must comply to, must be imposed through the product backlog. There are three possible ways for this:

  1. As part of the definition of done – I don’t advise this, unless there is an integration requirement that applies to virtually all user stories.

  2. As separate user stories – I only advise this for integration requirements that have explicit business value by itself.

  3. As part of the acceptance criteria for each related user story. – This usually has my preference.

In all cases, the enterprise architect is a stakeholder, and the product owner must work with the enterprise architect to make sure that all integration requirements are taken into account on the product backlog. It’s also wise for the team and the the enterprise architect to have good contact with each other. They have separate responsibilities, but depend on each other to deliver.

Permanent link to this article: http://agilethings.nl/functional-agility-vs-technical-solidity/

Apr 19

Kill the Khan

You don't need a kanban masterDoes Kanban need a master? With almost every training or presentation I do about Kanban this question often is asked. Because in Scrum you have the Scrummaster so in Kanban you should have a Kanban-master. Right? Well not exactly. First of all kanban leaves roles and processes as they are. Through the use of Kanban the processes might change and become more effective. Roles and functions might shift but they only change to solve bottlenecks and to gain more efficiency. Kanban can even work in a waterfall environment. All it does is visualize workflows so it is easier to optimize.

It differs from Scrum. I have seen discussions that Kanban might be the next Scrum but that is a whole lot of nonsense. Even though there are similarities, the models are different form one another. Kanban is a visualizer and is based on the theory of constrains. See where you have obstructions and eliminate them. Optimize flow by reducing speed overall and constraining workflow. Scrum has a set time box. A set amount of work based on earlier experience. And it has a scrummaster to help the team and the process itself. Kanban does not need that. Just setup a Kanban-board and keep doing what you are doing. Just make it visible and adjust speed. I’m sorry but that’s it. That doesn’t mean that it is much easier, it is just closer to what you already where doing. Scrum is a complete different  ballgame. It demands change and does almost the opposite of what people are doing. It uses points instead of time. It uses set time boxes and is especially designed to produce complex software. So it needs someone who is in control of the process (not the people).

So do you need a Kanban-master of Lord of Kanban or whatever strange name you might come up with. No you do not. It can however help to have someone in charge to make sure the rules of Kanban are followed. Someone who sets the board and delvers the various charts when needed. This can be a projectmanager but also a developer. As long as the person knows how Kanban works. Strangely enough a Product Owner seems to find a nice place within a Kanban driven company. One person (or more) who knows what is needed and can prioritize work. There is nothing said about having a productowner in the Kanban workmodel. Maybe because this role is needed. But please, don’t go as far as having a Kanmaster, Kanban-host, The Khan (yes I have seen this role) or the Kanban lord. Just do it. I mean, what would he or she do. Host the standup? Make sure that the Kanban stays intact. Optimize the leadtime. I haven’t got a clue. Change will come over time and you will find out yourself how to deal with the running of the kanban and the delivery of the product. Kanban is just the visualizer. Don’t make it bigger then it is.

 

Permanent link to this article: http://agilethings.nl/kill-the-khan/

Mar 29

Scrum is fun

Blog picture - Scrum is funI remember when I was young, and I was programming alone, you know, as a hobby. I was the customer, the requirements analist, the designer, the architect, the programmer, the tester and usually also the only user. It was great fun. Trying to solve complex issues gave me joy, and doing it successfully made me proud. And then it became my job.

Software development is a complex job. Doing it with a team makes it even more complicated. Add to this that customers usually don’t know what they want, and there’s your recipe for failure and frustration.

Over the years, companies have introduced various measures to reduce the level of failure, mostly by increasing control. As a result, the quality of the software has improved, but most of the frustration remained (not so much for me personally, but in general). The business view on software development was (and still is in some organisations), that after twice the time and for twice the cost, you get half of what you want.

In my opinion, the popularity and success of Scrum is thanks to the fact that it addresses, and solves, the frustration. It actually makes complex teamwork fun, with quality and productivity as by-products.

The two key factors in Scrum that contribute to more fun are improved communication and increased involvement of the business.

Communication
You have to understand that software developers, like most people, don’t like to share their work until it’s finished. They don’t even like talking about it until they are sure that they will be able to deliver. Forcing them to do that anyway, in a daily standup, results in three things:

  1. they discover that sharing a problem makes it less of a burden;
  2. they discover that their co-workers actually have useful input;
  3. they make sure that they make progress every day.

After some time you’ll see that even the developers that preferred working alone in silence, start communicating and working together. That’s a huge return on investment for just a bit of scheduled interest in each other’s work. It creates a more lively working environment, and consequently more fun.

Involvement
The other important fun-factor that a good Scrum implementation enforces, is continuous involvement of the Product Owner. Communicating with all stakeholders and managing the Product Backlog are very important tasks for the Product Owner, but it is equally important that the Product Owner is involved with the Development Team during the Sprint. There is simply no other way to make sure that the product is ¨potentially releasable¨ at the end of the Sprint. But that is the formal reason. Having the Product Owner close to the Development Team continuously, also increases the mutual understanding, and it makes communicating about functionality more important. This is a good thing for diminishing the hierarchy within Development Teams, where traditionally technical skills are most important. A team where various skills are equally important can become a well-balanced cross-functional team.

To work in such a team is great fun, it just might be even more fun than programming alone.

Permanent link to this article: http://agilethings.nl/scrum-is-fun/

Mar 27

Task driven Scrum

tasksAs a scrummaster there are a lot of things where you can focus on. Making sure userstories are written correct and that the team understands them. Making sure that the standup is done correctly. Getting a lot of info from the retrospective. And so on. But with almost every team I have coached I stumbled upon a very simple thing that has a lot of impact and one that is also very visible. It can be the first thing for a Scrummaster to act upon but also in most cases the scrummaster who is implementing scrum makes this first mistake. The mistake of the task driven Scrum.

In scrum we have the idea that the product owner provides the team with clear written user stories. These are stories with a function description of what is needed. The team estimates these userstories with scrumpoker and then determines what is needed to be done in order to get the stories done. The team writes tasks. Now a task is something that the team needs to do. Like write code, test code, cleanup something etc. Tasks are the jobs that the team does to get the work done. Some teams also estimate these tasks in hours. The largest task can be not longer then a day work.

It is to my opinion that the estimating of task is only extra work and does not add anything to the scrum. Ok, a project manager is happy with it but apart from that, no good ever comes from it. Especially when the team starts to track the tasks. I’m sure you have seen these sprint boards. Userstories on the left in the “To do” section and the task are being moved across the board. I have seen boards where every task also has a picture from the teammember working on it. Now this might work with a Kanban but not with scrum. When you only track tasks you get the task driven scrum. Individuality is endorsed.

When only the tasks are moved across the board a few things happen.

  • First of all every teammember picks his or here own work and working together on a single user story is in most of the cases not happening.
  • Next, because everybody works on various tasks, the change that any userstory is delivered at the end of the scrum is minimal.
  • And finally when your burndown is based upon the storypoints it stays flatline so you are not able to help the team or track progress.

In the beginning it seems like a good idea. Everybody is working on the software and it looks like the board is working and moving. But it does not work. As a scrummaster you should end this behavior as soon as possible. Bring the team back to one or two userstories to be worked upon. Teammembers might argue that they sometime cannot work on the same story. It is then a good idea to let them pair, test or write documentation. They have to work together to get the stories done and not just the tasks. Allowing everybody working on individual task is not effective and does not help the team and therefore the end product.

Permanent link to this article: http://agilethings.nl/task-driven-scrum/

Mar 22

The Little worlds of Agile and Lean

Lately, I have found myself being sucked in the little world of ‘Lean Startups’. Since I love being sucked into new little worlds, I do not mind this at all. I savor the feeling of being a traveller in a slightly different culture, learning their language. If a Frenchmen thinks of bread, he would call it ‘pain’ (something really funny if you’re an Anglophone driving in France), and it would probably be of the much lighter and fluffier sort than what a German person means when he says ‘brot’. I celebrate these differences, because I find it intriguing to see what the similarities and differences are.

I am a native UX speaker, who then learned the Agile language and I am now learning the Lean Startup Language. I feel like I need to know the language to really convey whatever message I deem useful, before I can successfully communicate and make meaningful connections.

Venn-UX-Agile-Lean

I’m reading Eric Ries’s book and will be reading a lot of other books and blogposts after that one. What I find remarkable is that the mindset he is trying to convey in his book is the same one I’ve adopted some time ago (and which I, until now, have always called ‘Agile’). The thing is, he applies this same mindset on a different part of the world, namely that part of the world that focuses on beginning businesses that focus on building and marketing a product. The startup world.

This was an eye opener to me, because I realized I come from a different part of the world, namely that part of the world that busies itself with designing and building products. The Product Development world (from a User Experience perspective). Both worlds have the same mindset. Both worlds keep saying the same thing. The labels we put on those things are just different. And with every word I’m reading, I’m trying to map out which label of the one world fits with which label of the other world.

For instance, if – in the book – I read the words ‘Customer Development’, I at first only understand it has something to do with ‘getting out of the building’. In my personal Mental Model (is this a UX word?), this will roughly translate as user testing, people research, customer feedback. Metrics would be called results from quantitative research, and customer archetypes are personas.

I wonder why these worlds have their own language.

I don’t care much about what we call things. I just want to be able to convey a relatively accurate message. But it’s good to know that we all mean roughly the same thing. Lean is Agile. Even though a Frenchmen’s mental model of bread is somewhat different from a German person, it is still bread. We may speak a different language, on a high level we apply the same mindset. It’s good to see that both worlds realize they can learn from each other and find value in combining these worlds. So let’s learn what words we all use and start combining those strengths!

Let me know if you have a more complete view on things, so I can broaden my horizon!

 

Permanent link to this article: http://agilethings.nl/the-little-worlds-of-agile-and-lean/

Mar 17

Why so serious?

expert-2Scrum has been around for almost 18 years now. Scrum was introduced in a research by Ikujiro Nonaka en Hirotaka Takeuchi at the beginning of 1986 in a Harvard Business Review and it was further developed by Jeff Sutherland in 1993. He, together with Ken Schwaber published it in 1985. So you could say that it has been around for while now. More and more companies adopt this way of working into their daily routines. And scrum teams all over the world don’t want anything else anymore. In order to provide al those companies and teams with the correct knowledge, various trainings are provided by certified trainers al over the world. Various books are written and all over the Internet more then enough blogs and whitepapers are published everyday.

Because of the popularity and high demand the balance between scrum experts and these demands is now almost four to one. There are four job-vacancies against every expert. This is huge but also a big concern. As more companies want to grow and adapt to the Agile approach it is very difficult to find good experts. The only ways to solve this is by training internally or hire anyone who claims to know a little bit about the subject. It is true that organizations like the Scrum Alliance and Scrum.org hammer on the fact that it is vital to have good certification. The Alliance is a bit more demanding in this then others but it may be clear that it is important that good scrum knowledge is vital to the success of it. But why is it so serious. Why not just buy a book. Go to a scrum course at you local training facilitator and be done with it.

We seem to forget that Scrum isn’t just a game you play. It is not about sitting around the table and toss some cards around. It is all about change. Change on all levels of a company. I wrote a few blogs about what can go wrong if you don’t do it well. And what might happen if you just do it half. You can almost compare it to the building of a house (although I hate comparisments like this). If you leave the design to someone who only read a book about building something, you can imagine that cracks will emerge. It is not something you do. After all, building a house or office costs a lot of money and you want the best. So then why are we so lightheaded about change that involves our own companies? As if there is now serious money involved. You need to take it very serious. You need to ask for a high level of quality and knowledge. It is not just a fun development thingy; it is a very powerful tool not to be taken for granted. So stop appointing the one guy who just did a scrummaster course as the senior change manager and demand more. It is good to start somewhere, better to try and fail then to never have tried it at all. But with so many people who claim to be knowledgeable about the stuff, you might consider some degree of measurement to make sure you get the best.  Developers have a saying. “Crap in is crap out” this is not just for writing software with crappy functional designs. Don’t settle for less but take it very seriously. Why? You company success might depend on it!

Permanent link to this article: http://agilethings.nl/why-so-serious/

Mar 07

It’s all about the input

header

Garbage in, garbage out

This is a pretty basic principle. But what do you expect? What are the odds that if you give poor descriptions of your vision and needs that the results will be as expected? 50/50? Maybe less?

Within the agile community there’s a lot of information to be found on processes and the output of teams. What I’m really missing here is the discussion about the input. And bad input is very often the main cause of bad output. This input does not start with designs or architecture but starts from a business perspective. In this article I’ll focus on the flow of input from an early stage: from vision to user story.

Some causes of bad input

However in no way a complete list, some causes of bad quality of input are:

The product owner role

This role is often taken too lightly. It’s not about writing user stories and whether to attend a daily or not. It’s about product vision, entrepreneurship, stakeholder management, domain knowledge, user research, strategy, leadership, innovation and passion.

Big design up-front

In some cases there was a phase in which there has been made for instance a functional or graphical design before the development team was involved. But we want to do the project agile because we want to be able to prioritize and build the software iterative. So we split the designs up and create a backlog based on the items in the designs. How is this different than implementing a big design upfront in basis? Do we now really know that we are creating the maximum business value?

“If the big design upfront was wrong, why should the quality be better if we cut it up?”

No focus on business value aka Quantity over quality

We really want it all. So we just define as much stories as possible. We do not really have to implement them all but we still define as much as possible. The bigger the product backlog the bigger the chances are that we will get a lot of functionality.

Why, What & How

We sometimes answer these questions in the wrong sequence. Sometimes customers start with the how and we go along with that (A man went to the Doctor) and sometimes we skip the what. To really define and secure the business value we really have to follow this sequence: Why, What and only then How.

 

The flow of input

What to do then? After seeing a gap between business and IT over and over again I started looking for ways to help the business to get a better connection with the way we do our agile projects. To help product owners to communicate better between stakeholders and development teams. I found some really helpful ways of thinking and tools which I like to use in order to create a good quality of input. I didn’t invent these tools or methods. This is the work of people which I admire for that. I’ll only describe a small part of each subject. I provided some links to their sites so you can get in depth information written by the experts.

The agile product vision board

We need a clear and common understanding about the goal(s) of the product we are going to make. We start by defining the product vision. We specify a vision statement, the target group(s), the reason why we should make or do anything (the needs), your crucial features (those can become your epics) and what value it is going to bring the stakeholders.

SampleProductVisionBoard

We now have a common understanding about the goal on which we can verify all the choices we have to make in the future. Whether you are a developer, product owner, stakeholder, user or tester. We know the target groups on which we can define our personas, we know which problems we have to solve/which business value we have to create for these personas and we have our top features. These top features we now can easily use for the next step: the story map

The story map

The reason why I like to use story maps instead of flat backlogs is because flat backlogs are very difficult to understand. Most of the time they need explanation for the people who are not directly working on it (stakeholders for instance). It is just a flat illogical list of splitted functionality.

A story map is a two dimensional backlog which makes your backlog and release planning both much better readable, logical and understandable. Not only for the development team but for everyone who can read basically. It will show you your planned releases and what they contain in one glance.

The principal is very simple (as very common with good ideas). At the top of the map from left to right are the “big stories”. Let’s call these activities. It is something an user wants to do with the product. The order of these activities explaines the behavior of the system. Underneath these activities we put our user stories, prioritized according to their value.

story_map_diagram

As Jeff Patton puts it here: ”I simply arrange the small things under the big things in a bit of a grid form.”.

If your story map is ready just take the top row(s) of features, the most important ones, and work them out in a product canvas. This set of features can be your minimal viable product. It contains only the features which you need to have your (first) version deployed. Now you can finally get some real feedback from the users you’ve defined in the product vision. Inspect and adapt.

The product canvas

This is something that helps teams to get the stories for the next sprint ready just in time. This gives a clear and focussed view on what there needs to been done on the short term to get ready for poker instead of a big design upfront. I found out that it is also very helpful for getting (UX/graphical) designers and architects, who are used to create designs upfront, faster in a agile mindset.

We take our most important features from the story map, add the personas, describe the journeys these personas can take, describe the constraints, do some basis or overall design and combine all this data to write stories which are ready for poker. This is the input for your sprint. And after the sprint planning you start over again with the next set of features.

SampleProductCanvas

Finishing up

As stated above, I like to use these tools to bridge some of the gap between business and development teams. To create a common understanding about what we do and why we do it. To do really successful (agile) projects we need everyone who is in any way involved to have that understanding. To maintain this we need to have this visible, understandable and accessible for everyone. I found that the examples I described above are great for that.

By taking flow of input serious, like we should take the PO role much and much more serious, we can create qualitative input. The odds that the output will be qualitative will then be also much higher.

For me there is one downside. I consider this a luxury problem: you really need a lot of room on the walls.

 

 

In-depth explanations:

Permanent link to this article: http://agilethings.nl/its-all-about-the-input/

Feb 26

Creative planning

planning the futureSomething that comes by now and again is planning. And with this I don´t mean the planning sessions within Scrum or planning work through the day. I´m talking about the planning that occurs in boardrooms and amongst managers. Often I am asked to provide a long term planning. How many sprints something would take and even the distribution of manpower despite of the use of Scrum. Swapping teams and team members and relocating work. In most cases I can prevent such question in becoming a real threat and I always refer to the importance of a roadmap and long term vision.

But despite of this at some point planning is needed. In most companies long term planning is done during elaborate planning meetings with excel or something like that. And most of the time amongst the managers. We all know those session where you are in a meeting and have to point out where you´re work is at in the planning and if you need more time or resources (I hate that word). During my agile journey I came across two companies that did something dramatically different, resourceful en excellent. They redesigned there way of planning and with that willingly abandoned micro-management and lack of overview.

The first company is a large distribution center in the Netherlands. A few years ago they implemented Scrum and Kanban for their software development, but management was still working with elaborate and boring planning tools and meetings. With the intervention of a Scrum coach they started to think differently. They started to work with the one thing their scrum teams already used. Stickies. Their boardroom was transformed into a information center and is now containing  a very long paper planning board. The rows are the various scrum teams and every column is a week. At every spot is one sticky. One sticky represents one sprint. So you can get an idea of what that might look like. A very large colorful plan board with only highlights on the various sprints. They only thing the managers now have to do is simply move stickies in order to make it fit. They know approximately how the sprints run and on what and when the teams are working on something.

Sticky Boardroom planning

Sticky Boardroom planning at CB Logistics

The second company I stubbed upon has an even more creative and even playful way to plan the people and projects. They use a Lego Planning board. And it is awesome. Horizontal you can see al the projects, and vertical the weeks (or sprints) Every member of the company is represented with a Lego blog. A two stud for an half day and a four stud brick for a day. At the bottom of the board there is a sort of resource pool. A pile of Lego bricks. Together the exact amount of availability of that member. So all you have to do is simply build your planning. Deadlines and delivery is represented by long 4 stud bricks to indicate certain milestones. Now this seems a bit waterfall but the company is agile. Even though they plan with hours they keep in mind that slack is needed. Nobody works for eight hours per day. And they know this. So a brick that represents half a day is this but with a little less. The fun thing is that the planning itself can go pretty fast. Every Friday they have a short standup meeting at the board and indicate where attention is needed. They move a few bricks and of they go. Not only does it work, it also looks great. It is fun and it is easy to understand.

Lego planning

Lego People planning at Hoppinger

In both cases the managers of these companies made the decision to abandon old-school planning and change things. Even playful things. After all a manager is just a person so why wouldn´t stickies or Lego bricks work for them and bring more fun and even overview. And we all know that overview is the real control.

Permanent link to this article: http://agilethings.nl/creative-planning/

Older posts «