Agile & Lean Product Development

A Practical Approach to Agility and Product Management

Page 5 of 7

Predictability in Agile Delivery

March 4, 2016 / / 0 Comments

It comes at no surprise that predictability of Agile delivery is a big deal. I would define it as the team’s ability to predict with reasonable accuracy which backlog items they will be able to complete either by the end of a sprint or within a certain timeframe (in case of Kanban teams). And predictability scales up: multiple predictable teams may make a shared program they’re a part of predictable and multiple predictable programs combine to a predictable portfolio. Organizational leaders look for predictable delivery in order to be able to make business commitments.

 

Nonetheless, I’ve always been quick to point out that predictability may not always be what one wants to optimize for. A key factor affecting the importance of predictability is where a product is in its life cycle. A very young product at the beginning of its life  will not require predictability. For such a product, especially if the organization follows approaches promoted by the Lean Startup, focus will be on defining an MVP and releasing it to the market as soon as possible, after which point the team will attempt to validate learnings as quickly as possible and pivot where necessary. Under these circumstances, iterating on the product quickly will be imperative. Therefore, I concluded, predictability is not important under these circumstances but something only more mature products (or larger, traditional organizations) require, right?

Recently, I realized that this it is the wrong question to ask whether a product requires its team(s) to be for what timeframe a development team needs to be predictable. If I’m iterating on my startup’s MVP, I need to be predictable, but maybe my planning horizon is only a week or two. If I’m maintaining a mature product, I may require high predictability in order to forecast 3 to 12 months out. Another factor necessitating high predictability is a market requiring long-term commitments from the companies serving it. Since the need for predictability is a function of the product needs, it’s quite possible that a well diversified company may have multiple products where the answers are different.

 

One caveat is that for the same product, one usually has to decide and pick one or the other: do I want to be highly predictable or highly responsive and able to turn on a dime? In most cases I can’t have my cake and eat it too.

 

My takeaway from this is: predictable delivery is always required, but it’s important to determine for what time horizon teams need to be able to make commitments and why.

Ease of Use

February 13, 2016 / / 0 Comments

As I’m using different software products and applications lately, here’s a question I’ve been pondering: What makes an application intuitive and easy to use? (Beyond that, one could ask what makes an app “fun” to use, attractive, addictive, etc., but those are different topics of their own.) Let’s assume an application meets user needs via its built-in functionality, what’s the difference between being perceived as user-friendly vs. hard to use?

I’m not a trained UX or Product Management professional, but based on what I’ve been experiencing, I’d boil it down to this:

  • Predictability and
  • Discoverability.

Here’s what I mean by those terms:

Predictability

An application is predictable when the user can…

  • Understand how its features work – without relying on documentation or “Help”,
  • Intuitively predict how the application will react to user operations – without specialized background knowledge, and
  • Reach correct conclusions about how to go about meeting his needs through the provided functionality.

One of my theories is that many applications get designed by developers, not UX experts. (No offense to developers – I’m one myself and do design my own apps!) Developers think about functionality differently, often approach it from a technical perspective and they inherently know to much of the application and its design already and can’t put themselves in the shoes of a casual or new user without that background knowledge.

Other considerations to enhance predictability are:

  • Consistent use of UI elements, fonts, color schemes, iconography, screen layout, and naming conventions
  • Repeatable patterns
  • Consistent paradigms

Discoverability

High discoverability means that the features and functionality of an application can be easily discovered by the user – again without relying on documentation or help. The user will not be able to leverage and appreciate an application’s functionality if it is difficult for him to discover that it’s actually there. If functionality is hard to find or practically hidden, there’s a risk of user never finding it and getting frustrated because he can’t solve his need.

If an application is well instrumented, i.e. user interactions (e.g. time on page, mouse interactions, scrolling, entry and exit points, etc.) are tracked, logged and available to the application provider, interesting insights can be gained about which parts of the application, features, and controls are used and how often. This information is vital as it depicts how users actually use the application which may be quite different from how the designers intended it. It may also uncover screens or features that are barely ever used, maybe because of lack of discoverability.

The dark side of discoverability, which should obviously be avoided, is overloading the UI with menus, buttons, and controls, which could overwhelm the user. The art is exposing functionality in a thoughtful manner. One technique that could help may be to create layers of functionality, i.e. primary functions, which are easily visible and accessible directly from the UI, and secondary functions, which are still easily accessible, but maybe only via other UI elements (instead of being exposed directly). Example: Microsoft Word allows me to quickly change a paragraph style via a single click of a primary UI element while inserting a footnote requires a trip to the menu. Once again, a UX professional might help provide some much needed skills in this area (and provide a counterweight to us developer types).

Overall, I think more attention needs to be paid to how we design applications. I guess in the end, I’m making a case for either engaging people with the appropriate education and experience or at least being more deliberate about how we design our apps and look at them from the perspective of an outsider, not from the angle of a technical insider. More advanced practices like instrumentation & application analytics, user research, user observations, interviews etc. will certainly also be invaluable in enhancing our applications’ predictability and discoverability.

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?

Closing the Impediment Gap

August 7, 2015 / / 3 Comments

In theory, it sounds pretty straightforward: an Agile team identifies an impediment and either solves for it or the Scrum Master takes it upon himself to remove it. Easy, right?

Internal Impediments

As long as it’s within the team’s or Scrum Master’s control to successfully deal with an impediment, this is a viable approach and
hopefully most impediments fall into this category. (Let’s call these “internal impediments”.)
PhotoAug072C123247PM

External Impediments

The problem is, there are these other impediments that are outside the team’s or Scrum Master’s control (let’s call these “external dependencies” because their root cause lies outside the team). What happens to those? Scrum doesn’t really say and is missing explicit mechanisms and ceremonies to deal with them, so it’s often left to the Scrum Master to figure this out.
During an Agile transformation, when a lot attention is paid to the maturing Agile teams and the overall progress, there is – in most cases – a person or a group of people in place who “own” the transformation. This group is a good audience for helping the teams resolve external impediments because it is motivated and empowered to keep the transformation on track.
 Photo Aug 07, 12 49 57 PM
In organizations which have been Agile for some time (maybe several years), often there is no clear ownership of “Agility” any more and it’s (hopefully) just part of an organization’s DNA and status quo. In these cases, the Agile steering committee has often-times already been disbanded and with that, there’s now a void in that a Scrum Master with external dependencies has no clear audience to get resolution. He may improvise, try to track down various involved stakeholders and affect organizational change himself, but, due to his lack of organizational influence, may not get very far. In those cases, these external dependencies often remain unsolved and the teams tend to get frustrated and numb to the impediments that never get taken care of. They feel the lack of organizational support, give up and often just “deal with it”.
 Photo Aug 07, 1 00 26 PM

What to do?

So what is the solution? During an Agile transformation and beyond, an organization should have a clearly identified group of Agile stakeholders, people who feel responsible for the success of Agile in the organization. Then there should be an explicit process for dealing with external dependencies that involves those stakeholders who will hopefully take ownership of these hairier organizational impediments.
That said, organizations aren’t always great at putting these mechanisms in place and might require to be given more specific guidance and tools. That’s where AgilityHealth (an Agile assessment and growth tool) can provide the necessary structure:
  • Resulting from regular strategic retrospectives, external impediments are identified and clearly flagged as “organizational growth items”
  • Those impediments are reviewed quarterly with an explicitly defined leadership group
  • That group pulls a number of these impediments from the growth backlog and commits to resolving them
  • Impediments are dealt with and resolved (likely in collaboration with the team)
  • After 3 months, the leadership group is asked to review with the teams the progress that has been made (this doesn’t imply that impediments shouldn’t be resolved faster if possible).
  • The cycle starts over.
Photo Aug 07, 12 59 20 PM
In essence, this process & tool create a new macro feedback loop as well as a quarterly “impediment sprint” with leadership. (In larger organizations, there could be several concentric layers of impediment sprints, e.g. involving portfolios first and then the overall organization.) Since this approach makes explicit the process, its cadence, the process participants and roles, it helps fill the gap that Scrum and other team-based Agile frameworks leave unfilled. Institutionalizing the process will provide accountability and heart beat that ensure these external impediments aren’t left unresolved.

 

I’m hoping this blog post has helped identify different types of impediments that need to be treated differently and will encourage organizations to be more deliberate with regards to how to deal with external impediments.
« Older posts Newer posts »

© 2025 Agile & Lean Product Development

Theme by Anders Noren — Up ↑