Attitudes Regarding Iterative Software Development Planning and Measuring

Attitudes Regarding Iterative Software Development Planning and MeasuringNowhere is the change in values of iterative development planning and measuring more important than in the management team. If the project is to iterate successfully, it must be managed iteratively.

The project manager must believe that an iterative approach is the best way to manage the project and must be prepared to set aside any inflexible, predictive, waterfall management practices that have been used before. This doesn’t mean that you should throw away all the good management practices and experiences you have built up over the years; good, disciplined project management is essential to the effective application of iterative development techniques. It is just that you must put aside some of the conventional wisdom about planning to give yourself the freedom to fully exploit the flexibility and power of the iterative approach.

The conventional approach to planning is prescriptive, based on the assumptions that the work which needs to be done can be predicted with great precision and that the unusual rarely occurs. This is true for many things—building a bridge over a highway or a standard family dwelling or a prefabricated commercial building, for example. These engineering efforts are technically predictable, and planning this kind of work is based on hundreds of years of experience. This experience has given rise to the generic project lifecycle in which the different types of project activities are aligned to the single phase that bears their name (i.e. Requirements, Analysis, Design, Code, Test and Deploy). Read More

Better, Faster, Cheaper, Happier: An Agile Balanced Scorecard

Better, Faster, Cheaper, Happier: An Agile Balanced ScorecardAdopting an agile approach has a lot of benefits, not just when developing software and improving team working but for all aspects of our business. When it comes to measurement, I recommend that we all take an agile approach and keep things simple, open and adaptive to change. 

A simple, intuitive score-card is essential for any team or organization embarking on any form of agile adoption or transformation. The Better, Faster, Cheaper, Happier framework provides a great starting point for motivating and measuring your changes.

Agile: What’s the Point?

Let’s stop and think about why businesses get involved in agility.  What is the promise of agility that is so attractive to businesses?  What we at IJI have found when talking to business people is that agility is appealing because of the belief that better products will be built.  Not only will they be better software products but they will be built faster and cheaper than before. The promise is certainly there  and this is what people want to see as they make investments in agile adoption and, in particular, any kind of large scale agile transformation. 

The other significant result claimed for agile ways-of-working is that there will be an overall increase in everyone’s happiness - happier customers; happier users; happier sponsors; happier purchasers, and happier developers. Read More

Dutch post: Meer heldere requirements: Kies de juiste verpakking

Mijn collega Kurt Bittner heeft afgelopen juni  tijdens IBM Innovate 2010 (Florida) zijn visie gegeven op de nieuwe rol en verantwoordelijkheden van de nieuwe generatie informatieanalisten. Wanneer je geen kans hebt gezien om zijn presentatie bij te wonen, bekijk die dan via Slideshare: Transforming the role of the Business Analyst. Hieronder volgende enkele observaties of veel voorkomende problemen die hebben geleid tot zijn visie:

  • Gebruikers verwachten andere  functionaliteit dan waar ze oorspronkelijk om hebben gevraagd.
  • Gebruikers eisen functionaliteit die ze nooit zullen gebruiken
  • Gebruikers geven tegenstrijdige of conflicterende requirements Read More

Light Weight Software Development Process using State Cards

Light Weight Software Development Process using State CardsIt is a well known fact that all software is different; all software development teams are also different. So, why should we expect software development processes be fixed? There is no such thing as “one size fits all.” Yet, it is also common sense that there must be something in common, as otherwise there is absolutely no way to learn from experience and mistakes. The challenge is then, to find a middle ground that is easy to communicate to the development team and stakeholders. In the next few blog postings, I will present a pragmatic approach using a deck of A8 (5 1/4" x 7 7/8") sized state-cards that is small enough to fit into your pocket. I will demonstrate how you can use the state-cards to understand the state of software development, how to define your lifecycle model and how you can use it to define your value streams. It is important to get your team to define and own their software development process and state-cards provides the building blocks to do this.

The posts to follow on this topic include:

1.       The Software Development Process Challenge

2.       A Solution through a Deck of Cards

3.       Dynamic Software Development Lifecycle with State-Cards

4.       Lean Iterative Management with State-Cards

5.       Organizing Design of Lean and Agile Teams

6.       Effective Work Assignment Using State Cards

7.       Applying State-cards to Manage Software Development

Attitude Regarding Teamwork and Collaboration

Iterative projects often require fundamental changes to the way team members work on a project. On a traditional project, it is easy to avoid really working together as a team. Everyone tends to have their own specialty and deliverables, and it is easy for a person to work in isolation and only interact with other people by passing documents around.

Successful iteration is very different, and requires a very interactive, collaborative way of working, involving:

  • Commitment - The whole team (including business representative participants) needs to be committed to making the project a success. This doesn’t have to mean working long hours or promising more than can be delivered; it means just doing whatever it takes to work as a team and meet the iteration’s objectives.
  • Focus - The team needs to keep focused on the iteration’s short-term objectives and not get sidetracked by other issues or activities. This is particularly true of the management team members, who need to stick to the iteration’s set of objectives after they have been set and agreed to with the team. The time to change the project’s direction is between the iterations, not during them. Read More

The kernel Journals 10: The essential does not change

The kernel Journals 10: The essential does not changeIn the previous kernel journals we have explored the value that development organizations can get from a process kernel that codifies what each and every project always has to do, in a way that is distinct and separate from how different project teams might choose to go about doing it, some benefits being:

Stimulating a discussion: Getting to needs

Stimulating a discussion: Getting to needsOne of the frequent questions we are asked is "how can I get the time to explore needs when the business says that it is already done - "it's in the business case", even when it is obviously not complete?  This is actually a pretty common occurrence - nobody wants to take time to understand needs because they think it has already been done. Read More

The kernel Journals 9: Is our way of working fit-for-purpose?

The kernel Journals 9: Is our way of working fit for purpose?We have seen in the previous kernel journals that a process kernel, defined in terms of the key domain entities, or Alphas, and their value state progressions, can give us a simple, shared view of what each and every project has to achieve (which is common across all projects), that is distinct and separate from how they might go about doing it (which may vary from project to project).

Read More

Attitudes regarding risk and change

Attitudes regarding risk and changeMost project management approaches address risk in a fairly superficial way: risk mitigation is viewed as an important activity, but one that is largely a distraction from the main effort of the project. Risks are identified at the start of the project, they are usually assiged to someone to address the risks, but these risk-mitigation activities are largely viewed as things that take away from the project work. In practice the risks are only identified once and then they are largely forgotten in the large amount of work to be done.

On a traditional project, change is viewed as a bad thing, and great efforts are undertaken to prevent it. Change disrupts the original plan, and it is the plan (and not value delivery) that is sacrosanct on a Traditional project.

Similarly, change must be embraced. Change results from new information, from feedback that something in the original plan will not result in the desired end result. Change is something that will occur as people get new information, but change is a good thing: it means convergence on the right solution. Read More

Dutch post: Meer heldere requirements: vermomde processen

De laatste paar dagen hebben verschillende mensen mij dezelfde vraag gesteld: “Hoe kunnen we meer heldere requirements krijgen”. Hoewel ik het eens ben dat het niet netjes is om een vraag met een vraag te beantwoorden, is het in mijn visie beter om in dit geval soepel om te gaan met die etiquette. En wel  omdat deze vraag eigenlijk niet zo eenvoudig te beantwoorden is. Bijvoorbeeld, waarom is dit nodig en welk probleem lost het op? Of, wat bedoel je precies met helder? En heb je heldere requirements en wil je er meer? En in dat geval, meer dan wat? Of heb je requirements die niet helder zijn en die je beter wilt kunnen communiceren. En zo ja, hoeveel beter?

Je zou kunnen zeggen dat dit gewoon spelen met woorden is. En dat klopt! Maar is het formuleren en communiceren van requirements niet feitelijk hetzelfde? Voor meer heldere requirements zijn een tal van zaken benodigd. Er is echter een belangrijk element dat vaak over het hoofd wordt gezien, namelijk inzicht in de structuur van taal en de wijze waarop taal wordt geïnterpreteerd. Read More

Page 6 of 16« First...234567891011...Last »