Kallokain

If you have worked in large Agile projects or programs, you may have noticed that there is often quite a bit of confusion about requirements, what the requirement types are, their purpose, how to write them, how to use them, and above all, what not to do with them. There are many causes for this confusion. Here are some of the more common I have seen: Nobody in the organization has read up on the requirements model it is using, so everyone makes their own interpretation. The organization deviates from a standard requirements model, but nobody knows which standard model the organization is deviating from, and/or there is no agreement about how they deviate from it. The organization has not documented its own requirements model very well. The organization mixes two or more different requirements models, often without realizing it. The organization has documented its requirements model, but finding the documentation is an epic project in itself, on par with when Henry Sta...

In the first part of this article series, I wrote about how using Cost and Capacity to control an agile software project can trap an organization in a hire and fire cycle that increases project duration and cost. This time, we will take a closer look at an agile control lever that works very well, except when it doesn’t: Business Value . When used right, the Business Value lever can be the most powerful tool you have to steer an agile project or program towards success. When used wrong, and it often is, the Business Value lever can be completely disabled, leaving management to pull a lever that no longer works, and no longer has the ability to steer the project. How to Deliver Business Value the Agile Way Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. — Principles behind the Agile Manifesto, https://agilemanifesto.org/principles.html Let’s start by looking at how the Business Value lever is supposed ...

Which levers should you use? When should you use them? Which levers should you avoid using? There is a subtle hint in the illustration. Agile methods brought us new ways of developing software, and new ways of managing software projects, programs, and product development. Unfortunately, I have seen very few, if any, organizations that make good use of the powerful new management tools they have at their disposal. Instead, they continue to use the same tools they used before agile, often with predictably bad results. In this series of articles I’ll provide a walk through of high level controls, their pros, cons, and how they relate to each other. The Levers of Death: Capacity and Cost Let’s start with the Levers of Death, Capacity and Cost . These levers are the ones I see used most often. They are not necessarily bad in and of themselves (well, firing people is bad), but they are easy to misuse, and often poorly understood. In most organizations I have worked in, it is assu...

Recently, I put my foot in my mouth while tweeting. This turned out to be a good thing, not only because it was an amazing feat of dexterity considering my age and body mass, but also because it lead to an interesting conversation, and thus, an opportunity to think things through, and to learn. I won’t recapitulate the whole conversation in this blog post, because you can easily look it up on Twitter . I’ll provide the tweet that kicked the discussion off though, and give you the gist of the conversation. I have invited everyone who was involved to read and review this blog post, so if I screw anything up, they can jump in and unscrew it again. It started with me tweeting:  That started up a conversation with Henrik Berglund and Beatric During. It did not take many tweets until I wrote: “There are plenty of things where SAFe has a very shallow implementation of important ideas. For example, they borrowed the idea of PI planning from Reinertsen, but ignored the limitations h...

Chrononauts V: Taking Flight by Henrik Mårtensson It's early in 2020, and I think it is appropriate to make a personal retrospective of the year that was. I am not quite as certain it is appropriate to publish said retrospective, but then again, if I decide not to publish it, I'll probably never get around to writing it. For me, 2019 has been a very good year, both privately, and at work. Let's get the personal stuff out of the way first. I haven't blogged much in this blog, but that is mainly because I have been busy, with work, and with other things. My hobbies, like digital art, may not seem to have much to do with my work on process and organization improvement, or my forages into Scrummastery, but actually they do. Almost everyone I know who is a really good software developer, or leader, or manager, does have some sort of interest in creative arts. Some play instruments or sing, others write, draw, are into photography, or some other creative activity...