Agile & Lean Product Development

A Practical Approach to Agility and Product Management

Page 6 of 7

Lean StartUp in Action

startup logoThis week I had the opportunity to participate in an innovation event by my company called simply “StartUp” in which the we were able to really put into practice the principles of the Lean StartUp.

The roughly 150 participants were asked to come up with new products or even businesses and prepare a 1-minute pitch; no slides, no gimmicks, just talk. After 1 minute, the buzzer went off and we were cut off – no extensions. We had to cover problem/customer need, provide a sample scenario, how we’d solve it, and end with a catchy product/business name. I was one of the roughly 45 people who pitched their ideas and let me tell you – this was tough!

Then all the pitches were represented on post-its on the wall and each audience member got 3 sticky notes to vote. Then the top 22 pitches were selected and the audience members self-organized into teams of 3-7 people.

The next step was conducting empathy interviews with consumers / customers which included walking up to strangers and trying to engage them in a conversation about our idea. The objective was to learn as much as possible and validate target audience, what are the real problems people have, do we really understand the needs, etc. This was a humbling experience for many. While all were bright individuals with lots of subject matter and industry experience, in more than (I’m guessing) 40% of the cases, the initial understanding of the problem/need were anywhere from slightly off to way wrong – a humbling experience! Then we could either pivot and adjust our understanding of the problem space and our solution – or give up.

Then came experiments with prototypes, be it on paper or online.

We also had to articulate and flesh out the business case, e.g. size of the market, revenue models, cost, competitive landscape etc. to prove that our solution translated into a viable business.

In the end we had to make a final, 3-minute pitch to judges (plus 2-3 minutes of Q&A) who then evaluated our product or business ideas and finally selected the top concept. The winning team will be able to work on fully fleshing out their idea for the next 90 days with the end goal of seeking actual seed funding. Exciting stuff!

Here are some of the key learnings from this process:

  • More often than not, we don’t know what people really want and would use. This includes seasoned product managers.
  • You can’t just work from a desk/office and figure this stuff out. You have to talk to people in the real world. Then focus on listening.
  • It’s good to fail fast and pivot. The first idea will rarely be “the one”. Only validated, viable ideas create real business value. (See my other post on Business Agility.)
  • Small, cross-functional teams work. People with different backgrounds and skills form teams capable of incredible things and are more than the sum of the parts.
  • Short presentations are very hard. Focus on the essence and don’t overload on details. Make your key points and connect to the audience both through key facts and at an emotional level.
  • Despite the focus on the essence of things, tons of legwork is needed to get there. Saying less is harder than more.
  • Finding a viable, sustainable business idea is not trivial.

The Lean StartUp approach works! This event gave us the opportunity to act and feel like entrepreneurs – outside of the comfort zone of our regular jobs, without job titles, processes, and support from the outside world or the rest of our organizations. Equipped with just our ideas and laptops, we worked long hours to create something new from scratch in just 54 hours while competing with dozens of other ideas and teams.

This had been a very valuable experience. If you ever have the chance to do something similar – try it!

What Kanban is – and what it isn’t

Nowadays Kanban is a well-established Agile development approach and various teams either dabble in it at least once or have adopted it for themselves. I believe Kanban can be a great fit under circumstances where Scrum with its fixed iterations can pose some serious challenges, e.g. working in more of a support or break/fix environment. Like everything else in life, Kanban has its pros and cons and while it excels at flexibility, predictability seems to be more of a challenge than with other approaches.

Some of the basic tenants and techniques of Kanban include

  • Visualizing your value stream
  • Optimizing throughput via work-in-progress limits
  • Measuring and optimizing flow
  • Reduction of waste
  • Pull-based system
  • Explicit policies
  • Classes of service

 

Some of these practices and techniques will need to be established early on in the adoption process, such as visualizing the value stream, while others will come later as the system evolves, e.g. classes of service. Another key prerequisite is that work items flowing through this system should be relatively small (or at least not large) and of similar level of granularity. This ensures items keep moving through the system.

Kanban seems “easier” than Scrum and for good reason since there are fewer “rules”, roles, and ceremonies. But Kanban isn’t trivial. In my experience, it requires more discipline than Scrum for a team to practice Kanban well and get really good at it.

Unfortunately, I’m seeing a lot of this happening: A team isn’t doing all that well with Scrum. They hear about Kanban and think they’ve found the Promised Land. Gladly they drop iterations. The value stream is often not thought about much and remains very simplistic. More often than not, other practices are also thrown overboard: no more planning (ad-hoc or with batches of items), retrospectives, sizing, and task decomposition. (They’re all waste, right?) Maybe the daily stand-up survives. Perhaps as a result of little to no planning and sizing, item size variances creep in and work items become less thought-out and defined. Then items get stuck on the board either based on their large size and/or external dependencies (which often would’ve been resolved previously with Scrum before an item would enter an iteration). If WIP limits exist, they’re either way too large (how does 15 sound for a team of 4?) or mostly ignored. Suffice it to say, classes of service and explicit policies never emerge, measuring is forgotten and items are pushed through the system.

What’s the result of all this? Lack of visibility & transparency, inconsistent and subpar performance, potentially poor quality, almost complete lack of predictability and more often than not stakeholders and business owners who don’t know what the status of their development projects is and when to expect features.

If we compare this end state to real Kanban, I’d argue there’s more resemblance to “anything goes” or the “Wild Wild West” than actual Kanban.

Don’t get me wrong: I like Kanban. Under the right circumstances and with a disciplined team willing to learn a new approach and get good at it, there’s tremendous value to be realized. But let’s not kid ourselves: throwing out iterations and using a board doesn’t make you a Kanban team. That’s what I would call “none-ban”. Adopting real Kanban takes work, discipline and requires evolution and maturation the same way a Scrum team will learn and get better over time.

Since Kanban does require a significant amount of discipline, I’m tempted to suggest that new teams don’t go straight to Kanban, but cut their teeth by building a solid track record and discipline with Scrum first. Then going to Kanban gives them a much better chance to continue with discipline in a less structured environment.

As mentioned in one of my previous posts, “structure” is not a bad thing and the less experienced a team is, the more it might need to become a high-performing team. A Kanban team, just like a Scrum team, needs to start basic and then evolve, which may involve adding additional structure (e.g. classes of service). We should be concerned about removing so much supposed “waste” that the team never makes it out of its Kanban infancy and stagnates way before reaching its full performance potential.

So let’s be clear about what Kanban is and what it isn’t. Otherwise we may end up giving Kanban a bad name despite of all of its potential benefits.

Business Agility

I think a lot of us dealing with Agile software development frameworks and practices on a regular basis have a good understanding of what it means to be “Agile” at that level. On the other end of the spectrum, there is “Business Agility” and that term is more amorphous and less understood. Below is my summary of what I believe the goal of Business Agility is as well as characteristics of organizations embodying Business Agility. Some of the definitions “out there” tend to be more lengthy, so I’m trying to keep it very succinct.

Goal

Business Agility aims to enable an organization to …Flexibility-Business

 

  • Respond quickly to emerging market needs and opportunities
  • Make critical decisions quickly
  • Reduce risk by testing hypotheses quickly, succeeding or failing fast
  • Innovate aggressively and often
  • Learn and evolve quickly based on short, frequent feedback loops

 

Characteristics

In my research, the following characteristics appear to occur most commonly in the context of Business Agility:

 

  • Focus on the customer
  • Self organization within small, cross-functional teams (development teams and beyond)
  • Decentralization of decision making
  • Empowerment
  • Adaptive and flexible
  • Experimentation and iteration on ideas (e.g. Lean StartUp approach)
  • Small batches and short planning horizons
  • Frequent delivery
  • Reduction of complexities and dependencies in favor of smaller, de-coupled autonomous units and architecture
  • Comfortable with risk, uncertainty and not having full, centralized organizational control
  • Shared purpose, vision, and/or values over detailed “processes”
  • View of the organization as “complex adaptive system

 

A number of these characteristics are rooted not in specific practices and techniques, but more in the overall company culture.
The notion of innovation I didn’t find mentioned all that often, but I took the liberty to add it because I think it’s important. Being adaptive and responding quickly to change are great, but they’re purely reactive and “outside in”. The concept of innovation is a proactive, “inside-out” effort, which in the end may be even more valuable in moving an organization and its products forward.

P.S.: After writing this post, a great article on the topic of Organizational Agility was published here.

The Art and Waste of Estimation and Structure

There has been a fair amount of noise and chatter around “estimation” in the Agile community lately and some of this debate is turning heated and sometimes almost religious. I certainly don’t want to get dragged into that, but at the same time this discussion has helped me see a few things clearer that I wanted to share.

I’m going to widen the term from “estimation” a little bit and call it “structure”. Structure can mean a number of things, all of which are somewhat elective in Agile:

  • Story estimates (in story points, ideal days, t-shirt sizes, etc.)
  • Story decomposition into tasks
  • Task level estimates (most often in hours)
  • Capturing of actual hours at the task level

Sometimes the structure is extended to include things like

  • Iterations themselves
  • Sprint burndown charts
  • Planning conversations and exercises

Some of the voices in this debate quickly judge the above structural elements as waste or in Japanese “muda” (although – as Scott Ambler pointed out – using a Japanese term for something we have a perfectly good term in English for is waste in itself; why waste brain power on translation? But I digress…).

A number of these structural elements are mechanisms to help create team predictability. Predictability in itself has taken a hit in the community and some argue it’s pushing us back to waterfall. I’ll make the argument that despite business model at a minimum an Agile team should have some level of short-term predictability, i.e. the ability to make a commitment / forecast for the next 1-2 weeks and be consistent in meeting it (I’m not talking about defect/break-fix teams here).

At the end of the day, a high-performing, stable Agile team is characterized by being able to produce a significant amount of high-quality output (working, deployable software) in a consistent manner. Despite what Agile maturity model you subscribe to, this always seems to be a big part of it.

I postulate that the less mature a team is, the more structure and with that “data” and visibility into what’s going on it needs.

Having iterations, tasks, task-level estimates, a burndown and the ability to compare estimates and actuals will help a team get better and become more predictable and ultimately high-performing. These structural elements are like training wheels to help the team mature and build some important disciplines.

Once the team approaches high performance, one might consider selectively removing some of these structural elements, assuming the team is mature enough to where those don’t add any value and aren’t required for other reasons. But one shouldn’t have to get rid of any elements, especially if removing them actually negatively affected team performance (which could happen if critical or too many elements are taken away).

On the flip side, doing away with all or most these practices and artefacts right away or never implementing them in the first place (because they’re perceived as wasteful), before a team is high performing, is dangerous and will prevent them from reaching their full potential.

Interestingly, I’ve recently had the chance to see teams that never used to have these structural elements and when they were introduced for the first time, they served as quite an eye opener for them and the additional visibility seems to help them greatly in fine-tuning themselves and reaching higher levels of predictability and performance.

In certain situation data captured by the team may not always directly benefit the team, but serve a purpose outside the team in other parts of the organization. The team may not care about story points, but maybe the Product organization finds them beneficial in understanding relative size of and progress against various epics that – without story points – wouldn’t have a tangible size. Capitalization rules may requires actual effort spent on a project to be captured. In those cases the team should probably not remove those structural elements.

In summary, instead of calling structure wasteful right off the bat and quickly judging it as bad, I think a more deliberate approach might be in order. Maybe the conversation should shift away from “if” and focus more on “when”. It’s not all good or bad; it’s about what things make sense and adds value under what circumstances, during which part of a team’s maturity curve. New and immature teams will require more guidance, data and visibility. Mature, high performing teams will require much less structure.

Three Levels of Optimization

Agile is pervasive and changes organizations, some more, some less. The same way as there are different levels of Agile planning (daily commitment, sprint, release plan, product roadmap and product vision), there are different levels of optimization an organization can achieve by applying Agile and principles based on the Lean Startup.

Layers of Optimization

1.  Development

When a development team implements an Agile framework such as Scrum, it starts optimizing a number of its practices, which has certain benefits. However, because the focus is only the development team and not the larger organization, the level of optimization achieved is limited. The Agile team is embedded in an organization that doesn’t holistically apply Agile principles, therefore the optimization is limited to the technical team and hopefully the Product Owner, which is the only part of the team intersecting with the non-technical part of the business. While this yields some benefits, they are limited.

2.  Business

When the whole organization “is Agile”, it becomes possible to optimize the entire business, which includes the Development group, the Product organization and even Finance and senior management as well as other related parts of the business. At this level, the whole business is optimized to deliver on business value, the product roadmap and vision. Many organizations stop here, but on 2nd thought, the optimization is often still based on internal assumptions. The organization delivers those projects and features that it thinks will produce the highest business value and deliver the best business results. (The Product organization is pretty certain it knows exactly what features the customer base needs and works with the development organization to ensure those assumed high-value features are delivered first.) These assumptions may or not be correct.

3.  Customer

Only once actual results after release to the customers are measured and fully understood can an organization truly optimize real business outcomes and validate the internal assumptions with external results. That’s where applying principles of the Lean Startup are helpful and allow an organization to release an MVP (minimally viable product), gather systematic feedback and then pivot on the information received if necessary. Only once those features hit production can those assumptions be given the litmus test of real customers and revenue plans be turned into actual dollars.
The bottom line is this: We obviously don’t want to practice Agile just at the team level. Many companies have understood that and strive to transform themselves to Agile organizations in a more holistic manner. While this is great, the true optimization of actual business results comes from optimizing for actual, validated customer outcomes and market adoption. Product life cycle approaches such as the Lean Startup are therefore complementary to Agile and needed to achieve the best possible business results.

My Problem with SAFe

I have a problem with SAFe.  It’s not that it’s necessarily a bad scaling methodology for Agile (I’m not familiar enough with it to make that judgment). It’s that it’s the default Agile scaling methodology.
Why is that? It seems that anybody who’s starting to research scaling online stumbles upon SAFe – and pretty much only SAFe. The conclusion drawn from this is that SAFe is the only option. SAFe has the advantage of having been early to market in this space and filled a vacuum. There have been and are other methodologies out there, but they are – for some reason – less known, less catchy and definitely not branded and promoted as well. Therefore SAFe is perceived as the only viable option. On top of that, it seems comprehensive and prescriptive enough to appeal to enterprise users seeking “all the answers” and an “enterprise-class process” they can roll out. If that does happen, the Agile mindset and culture may quickly be forgotten since the process seems provide all the answers.
Again, I’m not all against SAFe. There are good things about it. But it’s not the only option and has – despite the hype – remained somewhat controversial in the Agile community and has its critics.
Let’s not forget other ways to scale, such as Scrum of Scrums (admittedly a questionable methodology in terms of effectiveness and ability to scale large), Large Scale Scrum (LeSS), Disciplined Agile Delivery (DAD), the Spotify model, as well effective methodologies used and proven by Agile consultancies (let’s call them custom methodologies). For an interesting comparison check out www.agilescaling.org.
As always in Agile, let’s make sure we do our homework and pick an approach that’s appropriate for the given organization and problem space – instead of jumping straight into SAFe.

Agile Scaling and Organizational Culture

You might be familiar with Conway’s Law, which basically states that applications in their structure mirror the (communication) structure of the organization they were developed in. This law in itself is quite fascinating in and of itself.
During a recent Agile Open conference, I came to a realization related to scaling Agile that reminded me of Conway’s law. I venture to postulate that an organization’s Agile scaling method is the reflection of its culture and management style. (Maybe this shall be known as “Rosendahl’s Law” going forward, but I digress.)
What do I mean by this theory? If the organizational culture is that of command and control, it will choose an Agile scaling model which directly or indirectly embodies those values. In this case, an organization may choose SAFe since it – at least on the surface – seems to be more prescriptive and appears to provide more control.
If an organization’s culture is more characterized by empowerment and trust, it is more likely to choose a different scaling model, maybe just Scrum of Scrums or the Spotify model. As an extension of this theory, one might also predict that a command and control culture may lean more towards Scrum due to its (perceived) high predictability vs. Kanban which provides less clarity on roles, “process” and delivery dates.
What do you think, am I off here or have you seen  this “law” in action?
« Older posts Newer posts »