Agile & Lean Product Development

A Practical Approach to Agility and Product Management

Tag: maturity

Keeping the Agile Ship on Course

November 24, 2015 / / 0 Comments

After an organization has successfully gone through its initial Agile transformation, what does it take to “keep the ship on course” and prevent backsliding into old patterns and behaviors? That’s what I’ve been thinking about a lot lately. First of all, it’s somewhat of a fallacy to claim and celebrate success when it comes to an Agile transformation. While it’s very natural to want to acknowledge achievement of a transformation goal (e.g. “all our teams are now Agile!”), it’s really more the beginning of a journey than an end point. Some may argue that the more difficult work now lies ahead. (Just ask someone from an organization who’s removed from the original transformation by several years of “being Agile”.)

Why is that? During a transformation, a lot of attention is paid to what’s going on with Agile, the teams, metrics, etc. Ideally – if we approach this holistically – clear ownership exists and often a cross-functional steering committee keeps very close tabs on what is happening. These are stressful, but also exciting times and Agile and what it can bring to the business are “sexy” and new.
After the initial excitement wanes and success has been claimed, people’s attention starts to wander. Agile is now the “norm”, the status quo and eventually other, new and exciting things pop up and make us forget about all the effort we’ve put into the transformation. The steering committee may disband and the question “who owns this” now becomes more difficult to answer. In the worst case scenario, all off a sudden, there isn’t anybody left who feels responsible.
So back to the original question: what does it take to keep moving forward strong from here? I’ll use scientific phenomenon of entropy as an analogy (and I’m hopefully not offending any of the scientists among the readers with my poor-man’s understanding): the natural state of a system is … chaos! You’ll see this in your house if you’ve neglected to clean up for a week or two: stuff ends up all over the place, it gets dirty and messy. (Don’t tell me this doesn’t happen in your place!) My understanding of entropy is that if you want to counteract the natural chaotic state of a system, you need to apply energy to it. In your house, you need to make the effort and spend the time to clean up, put things into their rightful place and the reward for the applied energy is … order!
Energy is what we applied to our organizational system during the transformation by having people at various levels focus on creating order from the chaos and guiding individuals and groups towards a new, orderly end state. Once we relax and focus elsewhere, the system’s inertia sets in and old habits reappear as people slide back into pre-Agile patterns or simply just into chaos. Other anti-patterns include “Agile-on-the-surface behaviors”, where people seemingly follow the Agile “process”, but are simply just going through the motions without understanding the roots and spirit of the practices and ceremonies and therefore don’t receive many of the real benefits (maybe a new term Agile Lemmings is in order, but I digress).
So, to make the long-term journey of Agility successful, we need to deliberately and constantly continue to apply energy to maintain order and prevent chaos. Here are several things one should consider:
  • Have clear ownership: Figure out who really “owns” and is passionate about Agile in your organization. This could be one person, but having a group of people – potentially a cross-functional one – may be even more beneficial. (To stay with the “ship thing”, you need a captain.) Ideally, this person or group should also
    have the influence to make things happen and affect change. Maybe the Agile steering committee could transform itself into the Agile leadership committee and persist.

 

  • Know how to chart your course: Figure out where do you want to go, at least directionally. Have goals and in-between milestones. Determine which metrics (yes metrics!) you will use to see what course corrections are necessary and where attention is needed. Without any goals and metrics to guide you, how would you know where you’re going and if you’re doing well or not?

 

  • Nurture the community: Agile is not practiced by individuals, but by groups of people. There are obviously the teams themselves, but think of Scrum Masters, “QA people”, .NET developers, automation engineers, business units, etc. as communities of practice (CoP), i.e. like-minded people with similar goals and challenges. CoPs can be functional or cross-functional, local or virtual (spread out), within the same business unit or across. These are all mutually-complimentary CoPs. Create opportunities and spaces for people to connect, share and learn, in larger groups or regular small groups, in person and through electronic means. (Many of you will have heard of the Spotify model, which is more explicit about acknowledging these different groupings.) Invest in skilled facilitation.

 

  • Have a backlog: No surprises there, a backlog helps make things explicit, so why not have one (an Enterprise Agile backlog) during the transformation and beyond? It could contain additional teams to spin up,  improvements you’re planning on making, etc. Hell, you could even use it to plan monthly or quarterly “sprints” for your Agile journey or at least feed a Kanban board. It goes without saying that it could be a planning tool and an information radiator for those involved in “running Agile”.

 

  • Bake Agile roles into your organization: You won’t want Agile roles such as Scrum Master to be just something that somebody does on the side. That may work initially, but not once you make Agile part of your long-term DNA. Instead, you’ll want it to be an explicit, dedicated role with a title, a job description, skills and
    professional development. Overall the skills you need on the teams will be different as well and you will hire different kinds of people. So why not adjust the job descriptions and even reward systems to account for that?

 

  • Invest in coaching: A lot can be gained by having experienced, professional coaches with focus on Agile assist your various Agile teams as well as the “business side”. Not only will they help on the team level, but also be catalysts to organizational change management and achieving business Agility. They will also bring the right perspective and voice of reason and will not only be the first ones to spot the ship getting off course, but they’ll also be able to counteract those tendencies.

 

  • Know how to operate your model: Having a deliberate and explicit operating model for Agile will be hugely beneficial. How do you keep track of all your teams, their health and metrics? How do you know when to engage your coaches and for whichteams? How will you on-board and train new resource and get them educated and embedded in your Agile teams? What are you standards for tooling, internal or external training and certifications? Who in the organization is helping with propagating your Agile model (multipliers)?

 

  • Don’t be satisfied with just the basics: There’s more to Agile than just running basic Scrum (or Kanban) at the team level. There is scaling, (A)TDD, automation, various technical practices rooted in XP. Don’t forget that technical excellence and true craftsmanship are elements of Agility as well. CD/CI and DevOps should also keep you busy for a while. Don’t get stagnant!

 

  • Invest in training, education and outside perspective: Agile is evolving every year and like any field of knowledge, it takes effort and time to keep up. How will you invest in training and ongoing education? And don’t just stay in your four walls: get an outside perspective by exposing yourself to what’s going in the industry, in other companies, at Agile conferences and events. And don’t be shy to bring external thought and expertise into your organization in terms of external consultants. Fresh thought and a clear unbiased perspective are hard to come by from the inside alone.

 

These are just some of the examples of how one can apply energy to the Agile adoption and being Agile on a consistent basis in order to not just maintain the status quo, but continue to improve and push the envelope. (And avoid wrecking the ship… 🙂 )
What have you seen work in your organization?

Common Team Patterns

October 24, 2015 / / 0 Comments

During our company’s last internal Agile Open conference (see InfoQ), we had a session that brought together Agilists using AgilityHealth (an organizational assessment and growth tool). The questions we tried to answer were:

  • What common challenges do you see across your teams?
  • What are things that can be done to help the teams improve in these areas?

 

As people reported on what they had observed, the common patterns that kept repeating were:

  • The further out into the future teams looked, the less clarity they had.
    • In other words: while most teams were pretty clear on what they were building an iteration or two out, they had much less clarity around the longer-term product roadmap. (Think of driving in the fog.) The backlog gets filled “just-in-time” for the next sprint.
    • Root cause could just be simply omission by the product owner to communicate the roadmap or actual challenges planning further ahead.
    • One of the impacts of the lack of a product roadmap is that design and architecture decisions are challenging because the teams won’t know what future capabilities their applications will need to support, which may result in suboptimal design, i.e. architecture that won’t easily support future features.
  • Teams aren’t clear on the value they’re delivering sprint over sprint to the business.
    • While they produce working software on a regular basis and release it to production, they’re not clear on how these features support business objectives and what results they produce, e.g. incremental revenue, customer sign-up/retention, etc.

 

In the process of brainstorming solutions, the following ideas came to the surface:

  • If longer-term roadmaps do exist and the product owner simply doesn’t make the effort to communicate them the team, it’s an easy fix to make the time to review and walk the team through them on a regular basis. Frequent communication between product owner and team are key.
  • In the case where these roadmaps actually don’t exist, this becomes more of an organizational growth item and needs to be addressed by working with the organization to drive towards developing longer-term roadmaps, e.g. quarterly or longer.
  • It was also suggested to publish a regular newsletter which could describe to the organization what the longer-term plans are and what business results recent features have achieved.
  • Establishing certain metrics may also be useful, such as using business value points at the feature level.
  • The organization may also want to make a concerted effort to capture customer reactions post deployment, e.g. customer sign-up or conversion (as suggested by the Lean Startup), user behavior through site instrumentation, etc.
  • Even capturing anecdotal customer feedback, customer success stories or app reviews with comments and communicating those back to the team could be useful.
  • It was also suggested to internally showcase the product features and capture survey responses.

 

On the positive side of common patterns, it was noted that a lot of teams rated themselves highly in the culture dimensions, which includes overall happiness and is the sign of good employee morale.

If you’re users of AgilityHealth, which common patterns have you observed and which actions have you seen as successful?

What Kanban is – and what it isn’t

March 3, 2015 / / 2 Comments

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.

The Art and Waste of Estimation and Structure

January 28, 2015 / / 3 Comments

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.

© 2024 Agile & Lean Product Development

Theme by Anders Noren — Up ↑