Feeds:
Posts
Comments

Archive for the ‘Lean Startup’ Category

On Thursday the 20th of June I had the pleasure of co-presenting with Craig Smith (@smithcdau) at Agile Australia on “Visual Management: Leading with what you can see”. For the slides you can go directly to slideshare or click through the embedded contents below.

The presentation was video taped so when that is released I will update and provide a link.

Because it was a presentation on Visual Management I felt that it was quite important that visually it looked slick. I spent almost two hours a night, most nights for almost two months to get the 70-odd slides in the presentation. Some slides were cut due to the time constraints of keeping to 35 mins. Also due to time constraints we didn’t get the opportunity to cover items in more depth, in essence it was a slidefest of ideas and concepts, enough to say “hey, that’s a good idea, I could use that” but armed with the information to be able to seek out more.

To this extent I wanted to add to the slide deck some bullet points of thoughts that we didn’t have time to cover or extend further on. For those who were unable to attend I also wanted to iterate some key elements of the slides.

  • Firstly, I would like to thank a few people who made this slide deck happen. Four pictures were taken from @craigstrong and one from @caza_no7 (Ian Carroll’s) work. The Usability section of these slides was worked on with Usability expert, Matthew Hodgson @magia3e of ZenExMachima fame. Some photos were taken from the Dandelion and Driftwood cafe in Brisbane with the approval of Penny and Peter Wolff. Lastly, a number of pictures have been taken from where I am currently working at Superchoice, I am thankful to Ian Gibson for his permission to use them.
  • Slide 14, which discusses Value trees is an extension of Luke Hohmann’s Product Tree work. I have been using Value trees for a little while now to represent backlogs and am finding them more useful then a standard backlog, especially for identifying critical paths. Compared to a normal backlog they allow for recognition of the existence of dependencies and parallel processing. I am currently working on a whitepaper for these and with Luke Hohmann’s help should have it released fairly soon. The whitepaper will go into a lot more detail about what they are and how they work, so stay tuned!
  • Slide 16, the Timeline Board is sometimes considered an anti-pattern in Agile circles. It is an advanced form of a Gantt chart, but unlike a Gantt chart it is quite adaptable to real time change and exists for the whole team to have transparency and ownership of the work. I don’t use this type of board often but I do tend to use it for complex move sequences and have done so a few times. The x-axis and headers represent time. Usually this is done as a two way exponential timeline. The key milestone sits roughly 2/3 of the way across the x-axis. From that date it logarithmically goes forward in time. It also reverses logarithmicaly in time as well. For example, the headers could be 3.5 months, 2 months, 1 month, 2 weeks, 1 week, milestone -4 days, milestone – 2 days, milestone -1 day, milestone, milestone + 1 day, milestone + 2 days, milestone + 4 days, etc. Once the wall is constructed items generally don’t move. Cards do have a tendency to be added. The main thing that moves is the current time point. Anything behind it should be crossed off done, anything on it is in focus for the standup and anything in front is visibility of what is coming up.
  • Visual management isn’t just about software development. I have spent a good amount of time in my career applying it to other knowledge work areas.
  • Visual management’s audience isn’t just the team. It is about re-enforcing everything visually – for both the team, managers and customers.
  • Visual management isn’t just about a flow zone, it also incorporates many facets of other information.
  • There is a direct relationship between the level of complexity of the type of work that you are doing and the manner in which it is visually managed – generally the visual management is one degree of complexity less than the work itself. This is a new concept that has not been previously explored.
  • The application of software usability rules and how they apply to Visual Management is also a new concept that has not had a considerable depth of exploration. I am sure we will hear more from Matthew on this in the future (he felt it could have easily taken up the full 35 mins and I would tend to agree).
  • There is a misconception about the purpose of the readability of cards on the flow zone. Most think that the information needs to be retained. The key purpose of usability relating to cards is to be able to find it quickly and to be able to read it easily, not retain it. You want to be able to find it with little thought in stand ups. You want to be able to find the right card quickly when talking to the Product Owner. This is where usability and Visual Management becomes highly important. We don’t spend enough time being consistent and writing clearly when writing cards. As Lynne Cazaly beautifully mentioned in her presentation, if you don’t take the time to write neatly what someone else has told you then you are not showing respect for their thoughts that they have given you.
  • Achievements – I have mentioned them a few times on this blog. As part of this exercise of getting a slide up I somewhat simplified the generation of the tokens and the Agile Achievements playbook. If you are interested just send me a tweet and I can DM you a direct link to the content if you want to re-use it.

Lastly I want to thank Craig Smith for his help and support in doing the presentation.  I may be the Penny to his Brains (check Craig’s uploaded slide deck for the in-joke), but he is really the Will MacAvoy to my Mackenzie Mchale.

Read Full Post »

Seven years ago I was involved in an open debate at an IIBA meet up on the role of Business Analysts within an Agile environment. At the time my opponent contested that Business Analysts were defunct under Agile and were no longer required. I debated that they were still needed but that their role changed somewhat.

My main argument was that they were no longer the provider of lengthy requirements documents written in advance with little to no collaboration in the team. This didn’t mean that Business Analysts were no longer required to write any form of documentation, just the amount of documentation, the collaboration involved to reach a common understanding and the timing of when the documentation is done changed. With this reduced amount of time directly spent writing ‘War and Peace’ requirements they would instead use their time in a new skill set – as facilitators. I saw the role of the Business Analyst as being very compatible with the Scrum Master role, where the Business Analyst could encourage an environment of collaboration and ensure that the ‘promise for a conversation’ occurred. Business Analysts would still need to have skills drilling into the root cause of problems, to understand and analyse and question the business process, but in a good Agile team everyone would also have this skill.

Time has moved on and most of what I predicted for the Business Analyst role has come to pass within Agile environments. But I believe that it is time to make a new prediction.

We have come a long way towards mastering the art of building the product right, our next journey is to build the right product. After all, according to Lean principles, the biggest waste is the waste of overproduction and this can take the form of producing an unneeded or incorrectly targeted product.

Thus, in today’s ever shifting environment, I see the role of the Business Analyst as that of being at the heart of data. I see the role transforming to focus more on data analytics and the understanding of data associated with the product. Some may say that this is the role of the product owner, to which I probably wouldn’t disagree with and as such I see the Product Owner and the Business Analyst roles merging even closer together but with an incredibly strong focus on data.

So what is all the data that is being analysed about? Four things:

  1. Are we improving the number of customers seeking our product?
  2. Are we retaining our existing customers?
  3. Are customers getting value out of our product?
  4. Is our product revenue model generating net profit?

If the answer is yes to the above questions, founded soundly on data then your product is in a great place. If you cannot answer these questions then you really should start working on it (before you go out of business). For those of you familiar with the Lean Startup model then the above discussion should be something very familiar to you, for I believe the Business Analyst role should be centered around enabling the data gathering to support a Lean Startup approach.

You don’t have to be a start up to gather this data. You don’t have to measure once every three months. You can start measuring your existing product and incrementally improving on the four questions right now and everyday from this point onwards. Armed with this data  you can know whether a change you made today will make a difference to your business tomorrow.

Maybe the role shouldn’t be called “Business Analyst” anymore . Maybe we should start to create “Product Analyst” roles instead?

Read Full Post »

I had a considerable amount of trepidation when reading this book by W. Chan Kim and Renée Mauborgne. The title itself is ellusive and doesn’t lead the reader to understand the value that it might have for them. The subline is a bit more useful “How to Create Uncontested Market Space to Make the Competition Irrelevant”. A better byline would have been “Major differentiation through innovation”. You see, you will never make the market uncontested permanently. In today’s day and age competition is quick to catch up, maybe that wasn’t the case 7 years ago when this book was initially written.

I put what I had heard of this book aside and read it. Surprisingly for me, I enjoyed most of it. The first four chapters are what I would consider a must read for any manager, leader or product owner. Why? Because it fills a niche where there is a hole – how to create a differentiating and innovative business strategy for your products. It won’t guarantee that your strategy works. It won’t really help you execute your strategy either, but it is a sensible thought process for where strategic ideas could be lurking.

When I had finished reading Lean Startups for the first time my immediate thought after “this sounds like a great way to execute an idea” was “what idea should I execute?” This book gives you the tools to be able to seek such an idea within yourself. Blue Ocean Strategy is the Yin to Lean Startup’s Yang. Similar, but different. Each valuable, but together a powder keg.

So what is it exactly? Well despite what the authors will tell you, it is a strategy set of practices based upon a theory presented by the authors. The theory they have surmised after analysing numerous companies is that the only thing that makes a company successful is major differentiation through innovation (my words not theirs). All too often organisations spend an inordinate amount of time and money on catching up with other competitors or trying the win customers from the same pool. Blue Oceans (or as I like to call it innovative marketspaces) are about finding a new set of customers by differentiating in the market at a more macro rather than micro layer.

The book sets this up through a huge number of examples that clearly present their case. One of the key tools they use is a simple graph that anyone can use to describe their product and their product differentiating characteristics. Below is an generic example of such a graph. 

It should come as no surprise that Kim and Mauborgne are recommending finding out as much about your customer is imperative. But also that you should find out about all those people that are not your customers and why. By asking such questions you may gain insight and be able to differentiate to create a new customer segment. Their key suggestions for identifying innovative differentiation are:

  1. Identify cross industry opportunities
  2. Identify intra segment/industry opportunities
  3. Identify non familiar buyer potential
  4. Identify complimentary packaging opportunities
  5. Identify emotional appeal opportunities (Buyology does a better and more accurate job of describing how to do this)
  6. Exploit trends

Sounds sensible right? But real insight generally is sensible like this and they give excellent examples throughout to back it up. Most of the examples succeeded not because they used this strategy, and it should be noted that they have given no proof to their work nor were they able to recognise the success rate of innovation.

It made me think about the companies that I have worked for and the competitors that grabbed some of the marketshare. Certainly they found a characteristic, focussed on it and were rewarded. I could see some validation behind this.

Then I was curious about organisations that had actually used this and whether they have garnered success. Nintendo is known to be using it – Wii and 3DS were born and arguably they are having success. What is interesting is that as soon as a company creates differentiating innovations others will try and catch up – just look at Connect as an example. Another described project is the creation of the F-35 fighter jet. This jet was meant to be packaging intra segment opportunity – a navy, marine and airforce plane in one. The product characteristic graph for it is interesting but if you have a look at the project which is now eight years overdue and with a price tag of $1 trillion dollars you have to wonder whether it was worth it. Interestingly constant change of requirements has been labelled the cause for the blow out. So maybe the product charactistics were a too simplistic approach to the strategic problem?

But it did make me think about how this might apply to Agile. A graph could easily be made to demonstrate the differences between Agile and Waterfall. Similarly one for Scrum and Kanban. One can be created to define the opportunity that exists in the market. I have seen one done for managers and leaders – of what their current characteristics are versus what the strategy was to move them to it. It made me consider the Rightshifting proposition and the characteristics of the Analytic versus Synergistic mindset. 

This is a simplistic version of it, and no doubt I will have some (all?) elements wrong (read the 10% as low focus on and 90% as high focus on). Where can this graph be improved/corrected? What sort of things can we consider from a strategic perspective?

Lastly, whilst I do believe there is value in reading the book you should open yourself up to other thoughts in the community. The Blue Ocean Strategy has had many scathing reviews of it. Many of the points in the less than positive reviews I do feel are valid. Personally it is just another really simple tool that you can add to your toolbox. You won’t use it everyday, but one day you might need to take this tool out.

Read Full Post »

I had a great meal last week. It was more like a feast really. It started lunchtime on Wednesday the 20th and went all the way through to just past lunchtime on Saturday the 23rd. I am referring to the mystically labelled #klrat or Kanban Leadership Retreat held in Mayrhofen, Austria.

Going into the event I am not quite sure exactly what I was going to expect and get out of attending. I knew that I would greatly appreciate the networking and socialisation with similar practisioners, trainers and transformationalists (and I was in no way disappointed, all expectations here were well and truly exceeded), but aside from that I went into the event thinking that there was little that I wouldn’t be aware of or know.

Boy was I wrong. The amount of talk specifically on Kanban was probably only about 30% (subjective). Agile took up about the other 30% and the other 40% were models and concepts – some of which I knew but many that I had heard of and were re-inforced (eg Cynefin, Right-Shifting, Situational Leadership, etc) but a lot I had only briefly ever touched on or never heard of.

So what I primarily wanted to do with this post – is tell you about everything that I either heard about and want to investigate/read further or resonated significantly with me. These were my takeaways:

“Kanban is like Buddhism. You are quite welcome to keep your other religions when you become a Buddhist.” David J Anderson.

Facilitated by Liz Keogh @lunivore

In addition to having a lot to look over I also wanted to go into the experience with an open mind that some of my beliefs are wrong and should be fundamentally challenged. These are the quotes from people that made me ponder for many hours after where I could have it wrong:

  • “If you start with a presumption of innocence you will get further” (with regards to change). Liz Keogh eg. “I observed you doing x, does that match your recollection of events?”
  • “How can we get <this> outcome for you?” Liz Keogh
  • “We assume as change agents that everyone wants quick results” Torbjörn (@drunkcod)
  • “One of the worst things we can do (as coaches) is make walls for teams” (either @drunkcod or @jaspersonnevelt, both of these gentlemen were letting the quotes fly freely)
  • Companies are shifting more and more away from jobs for life. Loyalty doesn’t exist anymore (sound familiar?). We can expect a dramatic shift to more community based loyalty and involvement within. “A lot of people I would call colleagues aren’t in the same organisation, they are in this community”. This will lead to a framework of 70:20:10 shifting even further into the social area of learning (eg to 65:30:5), twitter (and even the unconference itself) is a classic example of this growing.
  • People have to want to change.
  • Instead of ‘Minimum Viable Product’ think of it as a ‘Minimum Viable Experiment’
  • and the many amazing conversations with Lowell Lindstrom @lowelllindstrom who enlightened me to why Scrum is a rulebook again and why Agile should never be all encompassing or swallow up general professional capability.

I want to take this opportunity to thank David Anderson, Katrin Dietze (@thisismui) and Sigi for all of your hard work in making this such a successful event.

Read Full Post »

Following up from my attendance at Agile Australia 2012 I wanted to provide a link to the slides and also a bit more depth of information. Unfortunately a few parts of the panel discussion overran and consequently a few things that I desperately wanted to say were unable to get out.

So firstly, for those that were unable to attend here are the slides:

A write-up of the panel can also be found in the mobile edition of the IT News.

I just want to take the opportunity to get across a few points that I didn’t get a chance to (or were slightly misunderstood):

  • Stop thinking of work as Project vs BAU. When you get to the root of who does the work often it involves the same people due to the shared service nature of organisational structures. You cannot possibly plan by looking at only part of your workload.
  • Everyone will game the system because everyone (rightly or wrongly) perceive governance to be a bad thing. You have to make sure that you consider paths of where people will game the system and either actively encourage it, gather data from it or find a way to shut gaming down in that area. For example, if your governance process categorizes projects that are < $100k as not requiring a certain level of delegation people will split the work down so that it is below $100k. Some organisations would consider this a bad form of gaming the system. I believe that if people can split the work down AND demonstrate benefits also split down then that is an excellent win for the organisation – because splitting it down has just reduced the risk of failure and enabled earlier delivery.
  • Understand prior to transforming your governance model what is broken vs what is working in the model. Understand the wait times, the sink holes, who the deliverables are for and why. For every answer you get apply some critical and root cause thinking to it.
  • Often processes and models get bloated because they are handling odd exceptions – especially exceptions of failed projects. Build a process that works for 80% of circumstances. Let the other 20% be handled by smart people.
  • RUN YOUR AGILE GOVERNANCE TRANSFORMATION AS AN AGILE PROJECT. You don’t have to do everything at once – incrementally deliver it. Once it is “in production” regularly retrospect it.
  • Who owns your governance process/model? Who is allowed to make changes to it? If your answer involves people that never do the activities involved inside of the process then you have just enacted an ivory tower PMO.

Additionally I wanted to talk about where I saw governance going in the future and what were its threats. Thankfully Martin Kearns must have read my mind and tackled part of that topic. But for my record here is my two cents – the biggest problem I see for governance groups going forward are Lean Startups.

People incorrectly think (like I did for a while) that Lean Startups are all about R & D or entreprenural internet corporations. Certainly it is what it was designed for but I have been having visibility that the concept goes wider. For me Lean Startups go back to what Agile really was meant to be about in the early days – delivering very rapidly, ideally each day, having the real customer involved and adapting to change when we find out that we got it wrong. All too often though we are delivering only once every two weeks or worst, several iterations because of perceived lack of “value” until it is 80% there. All too often we still have a Business Analyst as a proxy or a Product Owner that has never talked to a real customer in their life. When people realise that Lean Startups gives us an alternative model to give these back, people will be flocking to it.

Which brings us to the problem of how do you govern a Lean Startup? Think of it in terms of a normal project – usually you have a release date pegged, set budget, a backlog of scope and a clear definition of quality. In a Lean Startup you have a budget set only based upon a date. This date is the date under which your learning stops. If you don’t prove that you are learning then you are unlikely to get another drop of money. Incremental funding is core to Lean Startups – how does that usually work with our fixed capital financial year funds? It means you consider your capital spend a pot of money. Each time you approve another incremental drop of money to a Lean Startup you get your ladel and scoop out a bit of soup. You need to make sure you spend that pot wisely.

So what do Governance groups govern in Lean Startups? They govern learning:

  • Has the team learnt anything about Customer Value since we last saw them?
  • Has the team learnt anything about their planned growth model since we last saw them?
  • Has the team learnt anything about the way in which we can expect a return of investment (revenue)?
  • Are they learning fast enough? How fast are hypotheses being tested?
  • Do the hypotheses make sense given the data?

When I mean learning it doesn’t have to be good news – it just needs to be either validated or invalidated hypotheses.

Most governance models govern scope, time, cost and quality. How many ask the question “Are customers getting value from this product?”. How many organisations are any good at benefits realisation? We spend so much time in governance at getting better at delivering. We need to spend more time getting better at delivering the right thing.

Read Full Post »

When massive multiplayer online gamers work together as a team (called “Raids”) to defeat fantasy targets (called “Bosses”) they are repeatedly performing the steps of a Lean Startup – Build, Measure and Learn.

For raiders, “build” is working together to achieve the desired outcome of defeating the boss. They have a meta hypothesis – that the boss can in fact be killed and that once killed an item of superior value will be earned by one or more of the raid members. In the Lean Startup world there is also a meta hypothesis – that you can make a revenue generating business. In both cases it is possible to fail at this meta-hypothesis and disband the team never to try again.

But the incremental hypotheses is where it gets really interesting. Raid teams generally know how to operate together as a group. They have their own specialised roles. Additionally some people are able to be multi-disciplinary and can take on the roles of others. When first placed against a boss (who in business terms is a potential revenue generating customer) they will be armed with an initial hypothesis. It may be something as simple as what is called “tank and spank”. In a gaming world this means taking a standard stance of having one person taking the bosses attention, a few healers helping top him up and the rest of the team doing damage to take the boss down. In a Lean Startup world this would be starting off with a homepage and seeing who rocks up to the site and seeing what areas of interest they click on. For a very easy boss (or customer who has infinite time and interests) this might be a suitable strategy, but for a majority it will fail. What it will tell you though is some very basic information, potentially enough to start a new hypothesis.

You may have learnt that it will require another specialised “tank” role or that you need to reposition the team. In Lean Startup terms this would be a feature potentially being searched for very often but not implemented yet. This new hypothesis is then implemented. The team look at the results of their work. They use observation and actual data to determine where to improve and what to try next. Actual data for raids is obtained through tools such as combat logs and parsers that aggregate and display graphs of what is happening as the fight, or user experience across multiple customers for Lean Startups, is occurring.

For raiding teams it can take dozens of hypotheses before they defeat a boss. It takes a lot of analysing the data and re-execution of the fight in order to know whether you are on the right track or not. Teams may have a strategy built on multiple hypotheses that will consistently get the boss to 10 or 15% but never go past that amount. Ultimately they haven’t crossed the chasm. It is at this point in time that the team will need to pivot, drop their strategy and a large number of hypotheses and take a completely different tack. Only then is it possible to succeed. This is a very hard thing for a raid team to do. They have been pushing this set of hypotheses now for several hours. There is emotional attachment to the strategy. There is blame. There is tiredness. To change is hard when so much has been invested.

But if they do change, and they do succeed the rewards are sweet. There is a pride in having achieved the outcome and finally getting the hypotheses realised.

Interestingly raiding isn’t for everyone who games. The effort of having to work together as a team, of almost constantly being defeated, of looking at the metrics and not having a clue what tactic to take next – these are things that a lot of people just don’t have the guts for. They would rather sit on easy street and take on items that are immediately achievable, they don’t have an element of failure. That is fine, small risk reveals small rewards. For those that want to take risks there is the chance of bigger rewards.

Thinking you are suited to kickoff a Lean Startup? Maybe you should take on raiding within online multiple games and see whether you have the drive, committment and guts to keep failing before succeeding.

Read Full Post »

Moneyball has been credited within the Lean Startup community as a classic example of some of their principles.

I thought for those who haven’t had an opportunity to watch it that I would note some of the more powerful statements made in the movie. Some are slightly modified to apply outside of baseball so that you can potentially better relate it to your own environment:

  • The first guy through the wall always gets bloody.
  • This is threatening not just their business, this is threatening their livelihood. It’s threatening their jobs, it’s threatening the way that they do things.
    And every time that happens, whether it is a government, or the way they do their business, or whatever it is, the people that are holding the reigns – their hands on the switch, they go bat shit crazy.
  • Anyone that’s not changing – they’re dinosaurs.
  • There is an epidemic failure in the system to understand what is really happening. This leads people who run their teams to mis-manage their teams.
  • They are asking all the wrong questions. If I say it to someone I am ostracized. I’m a leper.

Read Full Post »

I have just finished reading “The Lean Startup” by Eric Ries for the second time and have been spending some time working with a team using the model. Joyfully it has made me think about opportunities out there and if I ever had my own push to be entrepreneurial what exactly I would consider.

As part of considering what sort of Lean Startup I would consider I wrote my ramblings down and then noticed that I felt something missing.

I would formulate the idea using the Gaddie Pitch:

You know how most…{existing commercial environment}?

Well what {Lean Startup idea} does is {how it breaks the mould from a value proposition perspective}.

In fact, {more value proposition information}/{recent success}

As I fleshed out the ideas further I considered the depths of what their value hypotheses and growth hypotheses were.

But it was missing something.

I wanted to know how the Startup idea also would create revenue for the business. After all, commercially, what good is a product if it has thousands of happy customers, a high and continual increase in customers but no means to make any revenue?

Eric Ries defines a value hypothesis as

Tests whether a product or service really delivers value to customers once they are using it.

and a growth hypothesis as

Tests how new customers will discover a product or service.

But what about the hypothesis that you will actually make money? Surely this is something that needs to be tested too.

Read Full Post »

In Part 1 of Scrum evolution over time we looked at the high level overview of Scrum and how it has changed over the years. In this post, part 2 of 5, we look at the roles and how they have adapted, or not, over the years.

There are three defined roles for Scrum – the Product Owner, the Scrum Master and the Team. The links from 2003 for roles were dead but I think we can safely assume there were three roles back then.

Product Owner

In the 2007 pdf we have the Product Owner defined as:

The Product Owner is responsible for representing the interests of everyone with a stake in the project and its resulting product. The Product Owner achieves initial and on-going funding for the project by creating the project’s initial overall requirements, return on investment objectives, and release plans. The list of requirements is called the Product Backlog. The Product Owner is responsible for using the Product Backlog to ensure that the most valuable functionality is produced first and built upon; this is achieved by frequently prioritizing the Product Backlog to queue up the most valuable requirements for the next iteration. The Product Owner is responsible for the success of the product.

In both March 2007 and March 2009 the Product Owner definition was:

The Product Owner has the following responsibilities.

  • Define the features of the product;

  • Decide on release date and content;

  • Be responsible for the profitability of the product (ROI);

  • Prioritize features according to market value;

  • Adjust features and priority every 30 days, as needed; and

  • Accept or reject work results.

The product owner is responsible for the first of the three Scrum ceremonies: Scrum Planning.

Within scrum.org the definition is now:

The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:

  • Clearly expressing Product Backlog items;
  • Ordering the items in the Product Backlog to best achieve goals and missions;
  • Ensuring the value of the work the Development Team performs;
  • Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
  • Ensuring the Development Team understands items in the Product Backlog to the level needed.

 The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.

The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a backlog item’s priority must convince the Product Owner.

For the Product Owner to succeed, the entire organization must respect his or her decisions. No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says. 

The ScrumAlliance definition of the moment is sparse with:

Product owner: responsible for the business value of the project 

Product Owner results and opinion

  • Aside from the ScrumAlliance’s less then detailed overview there can easily be seen a small transition of improvement of understanding of the role over time. Note how between the 2007 pdf and future content the Product Owner no longer became a person who has financial accountability. Basically the “Sponsor” part of the role was removed and the role then became a glorified Subject Matter Expert. No other role was created for the elusive person who had money, apparently they have no involvement in the project. I do like the concept of someone being accountable for the “product” but this is still a poor substitute for a real customer.
  • How does a Product Owner know that the features will result in market value? Is it an instinctual activity? Do they do market research? These are questions that I do not believe the Scrum method adequately covers. This is likely why other methods or techniques such as Lean Startup have grown in support.
  • Prioritisation evolved over time to be done as needed, which is a welcomed change.
  • I do like how the current scrum.org definition clarified accountability versus responsibility.
  • The scrum.org details on the Product Owner being a single, highly empowered person is also a welcomed clarification – but it does raise the point that this assumes teams work on one and only ever one product. The reality is that many maintenance, or Business As Usual teams support multiple products and whilst it is nice and warm and fuzzy to have a prioritized backlog from a Product Owner for each product being supported it still doesn’t help the team understand competing factors within the same organisation. Kanban does provide some explanations of how to handle this problem but  it certainly isn’t a part of any introductory readings.
  • It is interesting to see that the “accept or reject the work results” responsibility was added mid evolution and is now removed again. Who is responsible for this if the Product Owner is no longer?
  • I do have a question for the ScrumAlliance agilists – who is responsible for the quality of the Product? If the Product Owner is responsible for the business value, shouldn’t they also be accountable for the quality – after all, almost always when teams get pushed to deliver by a particular date it is quality that the Product Owner chooses to downgrade (at the future cost of maintenance and technical debt).

Scrum Master

In the 2007 pdf we have the Scrum Master defined as:

The ScrumMaster is responsible for the Scrum process, for teaching it to everyone involved in the project, for implementing it so it fits within an organization’s culture and still delivers the expected benefits, and for ensuring that everyone follows its rules and practices.

In March 2007 the Scrum Master definition was:

The ScrumMaster has three primary responsibilities in addition to leading the Daily Scrum meeting:

  1. The ScrumMaster needs to know what tasks have been completed, what tasks have started, any new tasks that have been discovered, and any estimates that may have changed. This makes it possible to update the Burndown Chart which shows the cumulative work remaining day by day. The ScrumMaster must also look carefully at the number of open tasks in progress. Work in progress needs to be minimized to achieve lean productivity gains.
  2. The ScrumMaster needs to surface dependencies and blocks which are impediments to the Scrum. They need to be prioritized and tracked. A remediation plan needs to be implemented for impediments in priority order. Some can be resolved with the team, some can be resolved across teams, and others will need management involvement as they may be company issues that block all teams from achieving their production capacity. For example, a telecom company recently implemented Scrum and found eighteen items on their impediment list, only two of which were directly related to Scrum teams. The others were company issues that needed management attention.
  3. Last but not least, the ScrumMaster may notice personal problems or conflicts within the Scrum that need resolution. These need to be clarified by the ScrumMaster and be resolved by dialogue within the team, or the ScrumMaster may need help from management or the Human Resources. Certified ScrumMaster James Coplien developed over 200 case studies of notable projects while working at ATT Bell Labs. He reports that over 50% of productivity losses were caused by personnel issues. The ScrumMaster must pay attention to them to ensure the team is fully functional and productive.

Additionally in 2009 the following was added onto the March 2007 version (preceding):

The ScrumMaster is a facilitative team leader working closing with the Product Owner. He must:

  • Ensure that the team is fully functional and productive;

  • Enable close cooperation across all roles and functions;

  • Remove barriers;

  • Shield the team from external interferences; and

  • Ensure that the process is followed, including issuing invitations to Daily Scrum, Sprint Review and Sprint Planning meetings.

In September 2010 it changed again:

The Scrum Master is responsible for ensuring that the Scrum Team adheres to Scrum values, practices,and rules. The Scrum Master helps the Scrum Team and the organization adopt Scrum. The Scrum Master teaches the Scrum Team by coaching and by leading it to be more productive and produce higher quality products. The Scrum Master helps the Scrum Team understand and use self-organization and cross-functionality. The Scrum Master also helps the Scrum Team do its best in an organizational environment that may not yet be optimized for complex product development. When the Scrum Master helps make these changes, this is called removing impediments.” The Scrum Master’s role is one of a servant-leader for the Scrum Team.

Within scrum.org the definition is now:

The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules. The Scrum Master is a servant-leader for the Scrum Team.

The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team. 

Scrum Master Service to the Product Owner

The Scrum Master serves the Product Owner in several ways, including:

  • Finding techniques for effective Product Backlog management;
  • Clearly communicating vision, goals, and Product Backlog items to the Development Team;
  • Teaching the Scrum Team to create clear and concise Product Backlog items;
  • Understanding long-term product planning in an empirical environment;
  • Understanding and practicing agility; and,
  • Facilitating Scrum events as requested or needed.

Scrum Master Service to the Development Team

The Scrum Master serves the Development Team in several ways, including:

  • Coaching the Development Team in self-organization and cross-functionality;
  • Teaching and leading the Development Team to create high-value products;
  • Removing impediments to the Development Team’s progress;
  • Facilitating Scrum events as requested or needed; and, 
  • Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.

Scrum Master Service to the Organization

The Scrum Master serves the organization in several ways, including:

  • Leading and coaching the organization in its Scrum adoption;
  • Planning Scrum implementations within the organization;
  • Helping employees and stakeholders understand and enact Scrum and empirical product development;
  • Causing change that increases the productivity of the Scrum Team; and,
  • Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization. 

The ScrumAlliance definition of the moment is again sparse with:

ScrumMaster: ensures that the team is functional and productive 

Scrum Master results and opinion

  • Phew… where to start on this one. I consider the SM role to be an art. There is this careful balancing act that needs to be at play in order to enable the team to deliver and creating a self autonomous environment versus advising and teaching. The SM role to me is ultimately about improving the teams whole capability at delivering. How does an SM do this? Through behavioural adjustments – people skills are key so March 2007′s third bullet point is incredibly important, but now lost again.
  • It should be the whole team not just the SM that removes roadblocks. What does an SM do if the roadblock is outside of their control though? Naturally they would help remove it but then this role is beginning to sound like a Project Manager to me… and Certified Scrum Master training says there is no such thing as Project Managers.
  • Shouldn’t the team work out which interactions are helpful or not? Isn’t that the point of the retrospective? The SM is there to question the team and to plant the idea that the interaction may not be ideal but ultimately it is the team’s choice. That is what makes a self-empowered environment.
  • Shouldn’t the SM be responsible for also ensuring the team is following first and foremost the Agile Manifesto and principles? I’ve seen plenty of teams that do the practices but then don’t treat each other with respect or have the courage to call out dysfunctions when they see them.
  • What is ‘Scrum theory’ exactly? I suspect it means reading a whole pile of books and blogs because the detail doesn’t exist anywhere else.
  • Facilitating sessions should be a temporary activity for the SM – ideally this would be rotated within the team as capability improves.
  • Ideally the SM role should not take more than 10% of a person’s time (assuming a 8 person team). How much time they actually need to supply depends on three factors – team size, team Scrum capability and the stage of development (ie first sprint or 10th sprint). A team that doesn’t know Scrum will take longer to depend less on their SM. A three person team will transition generally quicker to a position not requiring a dedicated SM faster than one with 10 people. A team that is in their first sprint are still going through Forming, Norming, Storming, Performing and so will depend on their SM more to resolve some of the personality issues. Most Scrumists say it is a full time job, I normally advocate a half bell curve over the life of the project. As the dependencies decrease the SM can then actually start helping delivery of stories (ie can contribute on a different level). Nothing in the descriptions above deal with the timing nor in the contribution levels of the SM.
  • The term ‘coaching’ is misleading. More often then not the SM is training and advising the team. True ‘coaching’, which I do believe is also needed, gets the team or individual to self reflect to reach answers to problems.
  • The recent scrum.org definition now combines the SM and Agile Coach role. These are different roles and shouldn’t be combined the way it has been explained. In a small organisation then without a doubt it would be combined but it really is a different ‘hat’ that is being put on. An Agile Coach grows the capability of Scrum Masters, provides an overall adapted framework for the culture of the organisation and works on changing the mindsets of senior executive managers. In the terms of Shu-ha-ri: the team is in Shu, the Scrum Master is normally in ha and the Agile Coach is normally in ri. Choosing an implementation model is no small feat either but as always comes down to its own implemention of Agile – ie create an implementation backlog, prioritise, estimate and work to deliver results frequently.

The Team

In the 2007 pdf we have the Team defined as:

The Team is responsible for developing functionality. Teams are self-managing, self-organizing, and cross-functional. A Team is responsible for figuring out how to turn the Product Backlog into an increment of functionality within an iteration, and managing its own work to do so. The Team members are collectively responsible for the success of each iteration.

In both March 2007 and March 2009 the Team definition was:

The Team:

  • Is cross-functional, with seven (plus/minus two) members;

  • Selects the Sprint goal and specifies work results;

  • Has the right to do everything within the boundaries of the project guidelines to reach the Sprint goal;

  • Organizes itself and its work; and

  • Demos work results to the Product Owner.

Within scrum.org the Team definition is now:

The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity.

Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback. Incremental deliveries of “Done” product ensure a potentially useful version of working product is always available.

 The Development Team

The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment.

Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness. Development Teams have the following characteristics:

  • They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
  • Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment;
  • Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;
  • Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole; and,
  • Development Teams do not contain sub-teams dedicated to particular domains like testing or business analysis.

 Development Team Size

Optimal Development Team size is small enough to remain nimble and large enough to complete significant work. Fewer than three Development Team members decreases interaction and results in smaller productivity gains. Smaller Development Teams may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver a potentially releasable Increment. Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to manage. The Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint Backlog. 

The ScrumAlliance definition of the moment is:

Team: self-organizes to get the work done 

The team results and opinion

  • Again scrum.org is coming up trumps in providing a really well thought out and detailed explanation including for the first time differentiating that the Development Team is subset of the Scrum Team.
  • The recent version of text from scrum.org also explains a lot further what ratio of time size is preferred and justifies this well. The 7 (+/- 2) model was too restrictive. People may often miss the fact that this is more a guideline then a rule.
  • I am frustrated with terms such as ‘Development Team’, ‘testing’ and ‘business analysis’ being used as eludes that Scrum can only be used for software development. Yes I understand that software development was it’s starting place but I would be more generic and say ‘Delivery team’ instead.
  • The use of the term ‘cross-functional’ is also a pet hate. Only the recent scrum.org definition covers the depths of what it means in adequate detail but even then a major point is missing – why is a cross-functional team recommended? Ultimately it is because you want to achieve the sprint goals without having to depend on external factors. As soon as you have dependencies on those outside of the team to deliver user stories within the sprint then you are introducing risk. Many people miss the fact that a cross-functional team means a team that is first and foremost focussed on achieving the sprint goals (and when I say sprint goals I mean more the product backlog items that have been pulled into the sprint backlog). All too often I see team that have coded and ‘delivered’ the software for the stories inside of the sprint, but the testing is incomplete at the end of the iteration AND the developers have chosen to start new stories rather than help achieve the sprint goal – ie they would rather develop then help out testing to get the sprint achieved. The second intent behind the cross-functional team is that these developers should be focussing on the goal rather then their specialised domain. Where this gets interesting for me is when this is a regular occurence – ie the team are often performing duties outside of their standard specialisation. This is a smell for me. When this happens often –  does this mean that the sprint goals are achieved? Yes. But does it do it at the expense of the team’s engagement? Yes. I would argue that if you put a great developer on testing duty for 75% of the project they will be highly unmotivated and it is for this reason that I actually believe the term should be “cross-skilled” rather than “cross-functional”. Cross-skilled infers that you can help out when needed, but that it shouldn’t be the norm where cross-functional is a little more open ended. My adapting too much to issues through a cross-functional team you are likely avoiding a particular flow constraint issue.
  • Some of the wording in the earlier versions is suggestive that the team is the one  that chooses priority – eg ‘selects the sprint goal and specifies the work results’. A clearer wording would be ‘determines how much can be achieved inside of the sprint and defines a way of working that will achieve this’.
  • ‘Demos’ is probably not referring to a showcase and more a ‘hey, we think we have this story right – can you take a look?’
  • You can see how a single word has a lot of potentially inferred meaning behind it – it is for this reason that short descriptions of roles and responsiblities are fraught with danger.
Anything else?
  •  I’m really getting a theme that the ScrumAlliance doesn’t want you to know anything more than a single sentence so that you have to go on training. A cynical person might think that it is a nice model to generate more revenue. For this I have to give scrum.org kudos of not shying away from giving something more meaningful to its readers.
  • So where is the Project Manager in all of this? Scrum says that no such role should exist, nor needs to exist in a self-autonomous team but then that eludes to a governance model that is not consistent in a lot of organisations. Often, organisations have a gating process before work starts and whilst delivering Sprints they require Steering Committee oversight – who should be part of this within the team? The Scrum Master? In an ideal world the Steering Committee would turn up to the showcase and see the output to be comfortable. In an ideal world system environments would be in control of developers and not require negotiations with an external team. But most Scrum teams don’t live in this ideal world. There are inevitably external factors that mean the team isn’t in full control of its complete destiny and this is where a project manager can be effective – in ensuring that the team is effective. They are externally, outbound focussed handling pressures outside of the team.
  • I have seen many projects that have software development components to deliver but at the same time have other components that have to be aligned – such as marketing/communications, training, business process re-development. Normally I treat them as all part of the one team as their stories will affect the success of the ‘product’. They have their own user stories which are prioritised against all the software development work, any dependencies are recognised. Because their work often only comprises < 5% of the end to end work I consider them part of the ‘extended team’. In this respect I have two ‘teams’ – one is the core team who delivers a majority of the stories. These are the people who are full time on the project. Anyone else is part of the extended team. This concept of two teams is not reflected in any Scrum content.

Read Full Post »

The Smithsonian is the world’s largest museum and research complex with hundreds of affiliated museums.

The Stoosonian is much the same but switch up museum with people and thought leaders. It could be the collective noun for people focussed on building such a network focussed on leadership in the same guise that the Agile Alliance crowd marketed the Agile Manifesto.

If you haven’t heard of Stoos then you might have been on holidays and not reading or following the twitter streams in the Agile community. In just one week I heard about it from three separate sources so the community is certainly abuzz. And I hope rightly so.

So what is Stoos? Take a look at their opening statement at http://www.stoosnetwork.org

Reflecting on leadership in organizations today, we find ourselves in a bit of a mess. We see reliance on linear, mechanistic thinking, companies focusing more on stock price than delighting customers, and knowledge workers whose voices are ignored by the bosses who direct them. All these factors are reflected in the current economic crisis, increased inequity, bankruptcies and widespread disillusionment.

There has to be a better way.

In January 2012, a diverse group of twenty one people including senior executives, business strategists, managers, academics, and lean/agile development practitioners from four continents, met in Stoos, Switzerland. We believe that we uncovered some of the common characteristics of that better way.

Stoos SwitzerlandFrom the stoos network page there is a myriad of information that can be found from the closed sessions that were held. A good portion of content has started being posted on LinkedIn and on a variety of blogs and other mediums including #stoos on twitter. In fact, the wide variety of mediums does mean you have the traverse around a bit to gleam everything that is being talked about but without a doubt the social stream is incredibly active.

I spent a few nights taking everything in and having a look around. The hype from colleagues lived up to my initial delve and then I began to test the waters on a few questions that I had. My first concern had been the target Stakeholder list. Now let me start that I am highly impressed that the group took the effort to do this list, debate it and then re-evaluate it. But two things jumped out on that list (and a third now that I have received some responses):

  • The C-section (eg CIOs, CEOs, etc) are rated so low (before and after),
  • First line management is non existent (but maybe that is due to deviations in definition of middle management)
  • Shareholders are rated at 0

The reason why I was concerned in particular about the C-section being so low is that every time I have done an Agile transformation within an organisation it absolutely had to have C-section level buy-in. This wasn’t an optional element. It was critical to success. Without C-section level buy-in teams were left to do Agile in stealth. Sure they worked better than before but there was a upper bound of roadblocks that endlessly re-0ccured and never got addressed because there was no organisational focus on being Agile. Culture of the team subtly changed but without C-section buy-in the culture of the organisation would never change.

This is critical to not miss. Agile, to get the benefit, requires cultural transformation. The Leadership problem is no different – in fact it is more often then not Leadership that drives culture. I’m not just talking about first line managers but also middle managers, CIOs and CEOs.

I then did a deep dive at the problem analysis done. The Stoos problem mind mapAgain I want to take a moment and congratulate the Stoos team on the job they did on generating this starting diagram. I would imagine they spent a few hours on this and as a starting map I think it covers most of the key points. To get it past 80/20 right it would have likely taken the whole two days.

If you take a look at the top two (not necessarily by priority) root causes you see shareholders and C-section management as the cause.

So my concern is that without doing something to address those two root causes that all this effort might be in vain.

Side note: would love to see the 5 whys applied to the root causes because they aren’t base root – eg Why are leadership skills missing in today’s managers?

Now I posed the question of C-section being non targeted in the twitter stream and was given a couple of nice links which is great information and a step in the right direction but again isn’t the root cause. The root cause as in the article is lack of education – and who do we need to educate? – the C-section, shareholders, and future to-be C-managers. Which is why I am happy that educators are high on the target audience. So there is hope, but maybe not in my lifetime.

What I love about the Stoos community thus far:

  • They are responsive, they are listening and they have some beautifully deep thinkers in there. A few of the questions that popped up in my mind today whilst I was a road-trip I was amazed to have found others ask and have had answers/responses to.
  • There is an appreciation that the command and control culture is thousands of years old – this is a very deeply embedded behavioural human trait. I am curious if it is neurologically driven somehow.
  • There is an appreciation that we actually have the answers on how to lead – it is just that for some reason it is not disseminating as expected. This is where I think some deep thinking root cause analysis needs to be directed towards.

As a test I asked a friend of mine who leads a team of ten about their leadership.

Do you think you are a leader or a manager?
A little of both. More detail then given.

How do you think your team perceives you – more as a leader or a manager?
Probably a manager.

Why did you go into management as a field?
For the money.

Not because you enjoy working with people?
No. I was smart, it was expected of me to progress that way.

How much time do you spend learning of new leadership and management techniques?
None. I have no time for that sort of stuff. I am too busy. 

So if you weren’t so busy you would spend some time learning how to be a better leader/manager?
Probably not. 

I could have continued going on to find the root cause but at that time my friend was starting to get the picture that I wasn’t playing nicely. Getting honest answers on this is going to be hard but we need to get some broad understanding (ie real metrics lean start-up style) to make sure we are going to make a dent in this massive global problem.

So lastly I want to say thank-you to the Stoos group for having the guts to tackle this and to make a great start on it. I am pleased that the group has such a diverse set of thinkers but would love to see a few other thoughtleaders included in the list – my pick would be someone who represents motivation (eg Dan Pink), someone for crowdscourcing (eg Dan Tapscott) and someone from the field of Neuroscience (to be honest Peter Burrows wouldn’t be so bad as he conceptually understands Agile and more importantly has some interesting team dynamic theories).

Keep it up and don’t take this blog as a big rant of criticism – the good certainly way outweighs the bad.

Read Full Post »

Older Posts »

Follow

Get every new post delivered to your Inbox.

Join 845 other followers