In Agile projects, when a set of requirements are received from Clients, it may consist of (a mix of) A few needs, objectives, goals and some partial stories (even though it would have come in a structured document). Re-organizing (re-arranging) those into a requirements breakdown structure (RBS) helps ask right questions to client to come out with what they expect to achieve from a Project.
Image above depicts the Fibonacci series, which is used as one of the sizing techniques for User stories.
Do you need improved agile estimates? If your agile process is heavily reliant on effort estimates, then chances are that you need to have the best possible estimates. Are your estimates already as good as they can be or do you need improved agile estimates?
Many people and companies think of Agile as some kind of Laissez-Faire approach to project management and software development. Agile is in fact a very rigid structure on how to do things so that there may be flexibility in what to do.
Agile project management is based on advanced project management concepts such as earned-value management (EVM) and phased rolling planning.
Agile software development is based on continuous quality control, other practices that are known to generate quality and a tight feedback loop with stakeholders.
There is no grand master plan or architect for an ant hill. Ants simply follow simple behavioural rules. The ant hill emerges as a result of millions of ants mindlessly following these rules.
In a recent, well written but smallish study, a team of researchers from Finland have tried to find where KanBan has benefits. In their setup, teams of master students were instructed to use KanBan in their software development projects and then interviewed about their subjective perception of the benefits of KanBan. For a full description of their research methods, please read the original article.
What the researchers did find was at least some support for the following effects of KanBan: Continue reading →
When you are building a home it is often quite possible to know in advance exactly which steps to take and in which order. You simply cannot start with the roof, continue with the walls and finish with the basement. You cannot apply the wall paper before the walls. Furthermore, you can easily predict how much time is required for applying X square meters of wall paper, or Y roof tiles etc. There are manuals available for project managers containing a wealth of data on standard work and its cost etc. In effect, it is possible for a competent construction project manager to create a plan for a project like this and to follow it with no small chance of success.
In software engineering on the other hand, things are a lot more difficult to predict. You cannot know in advance how long it will take to implement requirement X. This is because you are not assembling house number 1000 in a long line of identical houses. The whole idea of software engineering is to take something which is more or less unknown and transform it into something well known. So while designing the software is not really a predictable process impressing it on a CD and shipping it is.
Risks Levels Have Increased
Well, it turns out that the construction industry is not all that predictable anymore either. According to Everts et al. a lot has happened in the construction industry in recent decades. Where there used to be 70% of construction taking place on virgin land at the edge of the city with relatively predictable conditions there is now 70% of construction taking place in already built-up areas with of course a much higher level of unpredictability. Also, at least 50% of construction work is not new buildings but repairs, remodelling and the like. Working with old buildings is naturally much more prone to surprises, just like working with old software…
So far, the response of the construction industry have been to increase bureaucracy by generating more paper work for incident reports, change requests etc. If you are in the software industry, you will recognize this instantly…
… Move to Agile
Everts et al. takes things one step in another direction by surveying which skills would be needed and/or are lacking among construction project managers and building project managers in order to be able to work in a more agile way. They lists skills such as:
Conclusion – Not a Waterfall any Longer
Skills which are equally useful for a software engineer or manager! And that’s not all. With smart buildings the software component of the construction work is increasing. Intelligent building of intelligent buildings will be a new and major challenge for the construction industry. I guess I will soon have to switch to another example when I want to explain under which circumstances a non-agile project management style is most appropriate.
In my inbox today I found a link to an article about what constitutes success and failure in software development projects from a supplier perspective. While the authors were able to find three project success criteria from their systematic literature review they were unable to find failure criteria… The three success criteria were:
Short and long-term business benefits
Their final conclusion – that knowledge of what constitutes success or failure from a supplier perspective is limited – is very interesting. Perhaps the suppliers themselves are unclear about what constitutes a success or failure, especially in the eyes of their customers?
In agile projects we are supposed to keep everything we will do in our backlogs. The things we keep in there we call backlog items. With the help of releases, iterations, epics and stories we structure them into a work breakdown structure (WBS). Are backlogs enough to cover the complexity of building a major piece of software? In this essay I take a look at backlog items versus agile requirements. Continue reading →