Jazoon 2012: Agile Chartering: Energize Every Project Liftoff

4. July, 2012

In her talk “Agile Chartering: Energize Every Project Liftoff,” Diana Larsen presented approaches how you can set up your agile projects. Why is that important? When a rocket is launched into space, a lot of preparation happens to make sure the move from ground to space is smooth and successful.

Software projects often ignore this important step.

For example, it would make sense to check the commitment of team members. Commitment comes in two flavors:

  1. Yes, I want to do this
  2. … with the other members of my team

Another important question that each team member will ponder is WIIFM – What’s in it for me? Answers to these questions will have a huge impact on the success of a project.

Regulations are important but don’t forget that the human brain has a limited capacity. If you want them to follow the rules, you must restrict them to five tops.

Member Shields

Another strategy is to create “member shields” where each member writes their name on top of a shield like shape. The shield is then separated into four quadrants:

  1. Which skills to I bring into the team?
  2. What do I need to be successful in the team?
  3. What’s in it for me?
  4. Something personal. No dark secrets, just something that turns you into a person.

Write a motto below the shield.

Put those in a place where every team member can see them.

Context

Make sure that the team members know where the team fits into the organization. Post a 10’000 feet view of the company somewhere.

Risks

Agile development is all about risk management: Notice them, rate them, discuss them, act on them.

Good places to look for risks: Team boundaries and interactions: Who depends on the team’s work? On whom does the team depend? Does the team have everything it needs?

What does the team know about the future? What do we not know? What are opportunities and threats?

Remember the PAC triangle: Purpose – Alignment – Context. Every move of one corner influences the other two as well.

Also a lot of risks have their roots in VUCA:  volatilityuncertaintycomplexity and ambiguity.

Related:


Jazoon 2012: How to keep your Architecture in good Shape?!

28. June, 2012

Ingmar Kellner presented some tips how to prevent your architecture rotting into a mess. When that happens, you will have these problems:

  • Rigidity – The system is hard to change because every change forces many other changes.
  • Fragility – Changes cause the system to break in conceptually unrelated places.
  • Immobility – It’s hard to disentangle the system into reusable components.
  • Viscosity – Doing things right is harder than doing things wrong.
  • Opacity – It is hard to read and understand. It does not express its intent well.

(Robert C. Martin)

According to Tom DeMarco, your ability to manage this depends on control. And control depends on measurements – if you can’t measure something, you can’t control it.

How rotten is your software? Look for cycle groups (some package X depends on Y depends on Z depends on A depends on X):

  • They tend to stay
  • They tend to grow
  • They are a strong smell

Ingmar showed some examples in the JDK 6 (lots of cycles) and ActiveMQ (lots of cycles in 4.x, much better in 5.0 but again growing since then).

What can you do?

Use a consistent “architecture blueprint” that makes it obvious which layer/slice can use what. In the blueprint, layers are horizontal (presentation, domain, persistence) and slices are vertical (everything related to contracts, customers, users, and finally common code).

You will need someone with the role “Architect” who “defines the architecture, thresholds for coding metrics, identifies ‘hot spots'” and developers who “implement use cases, respecting the architecture and coding metrics thresholds.” All this is verified by a CI server.

At the same time, avoid “rulitis” – the false belief that more and stricter rules makes things “better.”

Some rules you might want to use:

  • The blueprint is free of cycles
  • Package naming convention that matches the blueprint
  • Control coupling and cycles with tools
  • Use tools to control code duplication, file size, cyclomatic complexity, number of classes per package, etc.
  • Reserve 20% of your time for refactoring

Following these rules can help to reduce costs during the maintenance phase:

  • 50% less time
  • 50% of the budget
  • 85% less defects

according to a study conducted by Barry M. Horowitz for the Department of Defense.


When Agile Fails …

18. June, 2012

When an agile approach fails, then remember rule #0: No dogmas.

Agile is all about being non-dogmatic. If a rule doesn’t work in your case, find something that works.

You need UML? Use it. UML only slows you down? Drop it. UML might have some value for you in some specific cases? Apply it in a smart way.


New Years Resolution: Stop being so agreeable!

30. December, 2011

How quick are you to say “sure, we can do that”?

Here are a couple of reasons to reconsider your attitude: Stop being so agreeable! by Erick Erickson.


Zero Bug Tolerance Intolerance

12. July, 2011

Jim Bird has written a great post about reasons to fix bugs and reasons to leave bugs alone: Zero Bug Tolerance Intolerance


Jazzon 2011, Day 3 – Turning up the heat – techniques for self-organizing teams – Joseph Pelrine

26. June, 2011

Turning up the heat – techniques for self-organizing teams – Joseph Pelrine

Joseph reminded us that teams always organize themselves, if we want it or not. Those social forces are pretty strong which is why agile methods have given up to fight with them. Instead, they try to prevent the worst and/or alert you early of problems.

The most important three words of the talk: “Leave them alone.”

But the result is probably not going to be the way you want. Also, team building this way can take a long time. Or it can be surprisingly quick. It can take as little as 2 seconds for a group of strangers to clap in unison (as he demonstrated in the presentation using the audience). One reason why this works is because we wanted it to happen. If part of the team refuses to be part of it, you’re in trouble.

When we say “self-organizing,” who or what is this “self” really? It’s a “system” composed of a group of people and their environment. This simple fact is an often overlooked. Renovating a shabby workplace can be better for quality than a raise or bonus. Listening to people and acting on their input is more effective than bringing in external consultant. Usually, they are brought in to make the “act upon” part more easy.

Every such system defines its own rules and responsibilities. Without any regard to what people want or what happens to them. Martyr anyone? The problem: We want people to do what we want without us telling them. Only if you ignore (part of) the system, you will fail because the forces in the system can be tremendous. Again, agile lists methods that often work but you should still be aware that there are reasons why changes to the system fail.

For example, Art Kleiner came up with the Core Group Theory: For every system, there will be a small group of people who control the system. Dictator in a dictatorship. If the boss doesn’t take control, the system still enforces that the “underlings” follow – they will make fun of the boss but they will still follow orders. Most often to the letter. Financial crisis: Small group of greedy people almost ruined the world’s economy.

One important point is that you need energy from the outside if the system’s equilibrium isn’t what you want it to be. Say your developers aren’t testing enough. You need some incentive for them. This external energy is consumed but it doesn’t necessarily alter the system permanently.  For that to happen, you must look at the system (people + environment) and find a way to make sure it’s in the system’s best interest to change (and not only in the people’s best interest!)

How can you do that? You turn up the “stress” or “heat.” Note that too little heat and nothing will happen. The resistance of the system will simply swallow your efforts. Too much heat and the system will retaliate or overreact. So it need to be applied with care.

One way is to use the physical formula PV = nRT which means pressure * volume = temperature. You can increase the temperature (the heat) by increasing the pressure (add more tasks) or by reducing the time to complete the tasks.

Another is to look at the system as a star with five tips: Attractors (like bonuses), boundaries (who is on the team, who isn’t), identities (who was which role/responsibility), diversity (homogeneous systems tend to inbreed) and environment.

Which means you can try these things:

  • Offer a price like a holiday or free pizza for all (attractor)
  • Add/remove people to/from the team like mixing the testers with the development team.
  • Move a difficult customer to a different support guy
  • Bring in new blood and ideas
  • Get them new computers, remove the telephones so they don’t get interrupted every 11 minutes.

Remember: Changes are like really long hikes; one step at a time.

Links:


Thoughts on agile requirements engineering

24. March, 2010

There is an interesting German article about agile RE: Gedanken über agiles Requirements Engineering