Posted: September 26th, 2011 | Author: greger | Filed under: Project Management, Software Engineering | Tags: agile software development, commentary, kanban, project management, research results, scrum | No Comments »
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:
Read the rest of this entry »
Posted: August 16th, 2011 | Author: greger | Filed under: Project Management | Tags: agile, agile software development, business 901, commentary, kanban, lean, podcast, recommendations, scrum | No Comments »
Here is yet another great installment of the Business 901 podcast. This time on being agile on the enterprise level part 1, part 2.
I agree with most of what is said in the podcast, especially that there is no “one size fits all solution“. Different teams have different needs. Some people need Scrum, other Kan Ban and yet others just a general idea of how to do Lean.
Posted: October 5th, 2010 | Author: greger | Filed under: Project Management, Software Engineering | Tags: Anthony White, Claes Wohlin, kanban, project success, requirements, requirements abstraction model, requirements lifecycle model, scrum, software engineering, Tony Gorschek, xp | 3 Comments »
Requirements are highly controversial in software development. There is always too much and too little requirements. They are often blamed for project failure or seen as required for project success.
I have seen cases where there were too detailled and complex requirements. The result was that everyone worked around the official requirements and used other more informal requirements.
I have also seen cases where the requirements were way to unclear. It became impossible too know for certain what they meant or when they had been met.
In agile software development, the supplier (ideally) works closely with the customer to clearly define requirements. In practice, this is not at easy at it seems. In my experience many customers and end-users do not know what they need before they see it.
There is a host of different techniques that can be used to improve requirements engineering in software development. Agile methods provide a number of methods such as iterative and incremental development, user-centred design — always available customer, acceptance test-driven development etc. About a recently published book on Agile Software Requirements.
Something that can really help is a good requirements life cycle model. In Scrum and XP the default requirement has approximately four states:
- In product backlog
- In sprint backlog = not started
- In progress
Sometimes a more complex requirements life cycle model is needed. One such model that I have enjoyed working with is the requirements abstraction model by Gorscheck and Wohlin. In all fairness, I should mention that I first started using it on the recommendation of Johan Natt och Dag. Some of the states used in the requirements life cycle model of the requirements abstraction model include (and a few of my own added as well):
- Internally prioritized
- Additional custom states not mentioned in the model such as Implemented and Verified
- Here I usually add Retired
This more complex model is perhaps better adapted to methods such as Kanban (more here) or SPI-LEAM, by Petersen and Wohlin, than Scrum and XP mentioned above.
Today, Google alerted me about an interesting research article by Anthony White where a number of different requirements lifecycle models are analyzed from a systems dynamics perspective. The main model considered in the article is considered as “uncontrollable and unobservable”. While I am not quite sure about the value provided by the research presented in the article, it was an interesting read.