Agile Ruminations

Some thoughts on Agile software development methodology.

What do people say about Agile? The following content is gleaned from:

What gets put here? If a point resonates - it gets a mention.

Agile Software Development

Why is software engineering so different and difficult - the Bridge Construction Analogy

Why is software engineering so different and difficult when compared to other forms of engineering?

If you want to build a bridge, you do what you did when you built your last bridge. The geology and dimensions may be different, but someone will have build something similar - it's a matter of "copy and pasting" the design.

(OK, I'm aware I've just trivialised civil engineering - but you get the gist.)

Software is rarely like that. So how do we manage it? AHA, lots of documents and plans - just like building bridges. (Oh no! - That's the waterfall approach!)

Waterfall?

Waterfall, also known as Plan Driven, follows the process of:

Waterfall methodologies follow standards (MOD, DoD, ISO, EIA, IEEE.) And are typically what we've been taught at college.  These methods not only manage the process of the actual project, but also have scope to manage the process itself, and "tweak" processes as required.

What's good about Agile over the Waterfall approach?

Process getting in the way

Explore empirical methods.

Identification of patterns.

How do you define Agile? (Agility)

The fact that there is only so much that can be identified, planned and anticipated at the design stage before you have to cut code.

Each Software application is new. (Not like a manufacturing process.) Because each app is new – that's why mistakes happen. Haven't done it before.

The customer doesn't know what he wants. So what you deliver will have mistakes – you and your customer failed to communicate clearly.

They do know what they don't want as soon as they see it!

Agility is keeping the customer / developer feedback loop short.

Identify problems at the earliest possible time – before you've spent ages going down the wrong path.

Agility is a set of practices / methods pinched from other methodologies (s/w and management)

It's quick and nimble.

Smallest amount of "process" required to get the job done. This does not mean that the process adopted is shoddy or informal. It's "tight" and well disciplined.

Feedback is what drives the project forward. As an engineer you know that short feedback loops give you information more quickly.

That means high bandwidth communication with the people within the project team as well as good communication with the customer.

Agility is identifying the customer's needs. Deliver what they want when they need it. Not anything else.

Agility is not the waterfall method where you attempt to completely and thoroughly identify 100% of the requirements before starting the design.

(That's totally dysfunctional. That approach is the result of 1980's college courses. Life in not that easy!)

Is Agility Hacking?

Hacking is the hack it and bash it approach. (A term my college friends loved to use - winds up lecturers big time!)

Get a preview to a customer quickly. This will be quality code, with a reduced set of features.

Rapid demonstration and quick release.

You need process. Agile (XP Scrum) all use good practise. There is still the design process.

Regular customer demonstrations are vital; involve the customer. NO SURPRISES You never want surprises. They are bad, and make people very uncomfortable!

If you don't know what you're supposed to be building, start somewhere, get the customer in the loop; iterate, figure it out, explore ideas. "Is that what you want? Is this what you mean?"

Educating kids is eased by "lying" to them. Teach them by putting over facts and procedural steps. Use models and exemplars. You can then set them exams. Students that learn parrot fashion grow feathers, will get good marks. (Squawk - pieces of eight.)

Real life is not that simple.

But if the problem has been "done before" - may be telecoms or financial – then there's very little vagueness and uncertainty. The approach there may be is to pick the best components off the shelf, or use design house in India. This is still agile: a different approach, but not hacking.

Agile means test driven development and continuous integration. The team and the customer do not want surprises. (NO SURPRISES)… This is very rigorous, more so than any other methodology.

Hacking implies a lack of forethought.

Hacking means understanding. (A hacker takes things apart that were never intended to be taken apart.)

I took radios apart as a child. I now know what every component does in a radio. That and a couple of City & Guilds  courses! And I dissembled Z80 Galaxians, 8048 CB synthesizers, 6809 cross compilers... That's how you learn!

Hacking is learning. There's a curiosity of knowing what's going on inside.

Hacking is about knowledge and understanding. That's agile. As you hack, you are consistent – you use patterns. You're methodical.

It's disciplined. It's not cowboy coding. YeeeHaaarrr!

Agile lets you be flexible and adaptable as you move forward from one project to the next.

Architecture and hacking. With a small component hacking, may be appropriate. With a large system you need an over-seeing role – an architect. That role cannot be hacking. That role treads into business, and leaves code monkeying behind; what is the completion doing? where's the market going?

Walking in fog using Waterfall, Hacking and Agile

Imagine you have to walk a mile down the road in the fog.

Using the Waterfall approach, you'll have a complete plan up front. Good luck!

A hacker would close his eyes, and only stop to reconsider if he hits a tree.

With Agile you would have a thoughtful plan for the next 50 yards. At each step you re-evaluate and make another thoughtful plan.

Prices and the contractual relationship with customers.

Customers live a world of budgets. How do you price projects that follow the agile methodology?

Depends on an existing architecture. If there is one in place this will help you with pricing – look at previous iterations.

If there is no existing architecture in place – get an end to end prototype going and visible as soon as possible.

Build a flexible relationship with clients. The "you changed your mind – that will cost you!" approach is too easy and will doom any relationship.

Build up trust over time – not fixed bid.

May be a staged payment. We don't know what you want. Drop us 3%... we will start prototyping.
Agree on a small scope of work to resolve uncertainties.

Is Agile prescriptive?

No. There is no software methodology that fits all. Must mix and match. That's the meaning of methodology.

Be iterative! How you talk, communicate – no one way of doing things. Be adult.

You must be disciplined with these "sets of practises". You are / must be accountable for the work you're doing.

Teamwork. You must communicate what you're doing (verbal written or demo.) with your other team members. (As well as the customer.)

Be open-minded, ask questions.

Identify the problem areas of the project. Some bits will be grabbed with glee, taken and farmed off easily. There may be an aspect of the project that nobody knows how to approach. Bring in experts, use pair programming to help figure it out.

Agile – hard the first time, Read the book – but what you adopt will be hard the first time. You've 10 ft of documents and no code written yet: you know there's a problem. Get some team members that have done Agile before. May be get outside help. Hire a friendly contractor?

Understand test first programming. How to do it. Specifying test cases.

Look at "exploratory testing". New advance in Agile. Read "Balancing Agility and Discipline: A Guide for the Perplexed" by Barry Boehm

Self control, extending to paranoia? (Yes, if you're involved with testing!)

How does Agile scale? Teams of teams on large projects? Teams in different areas of the world.
Other communities and cultures.

I have worked with the "Bangalorians". Lovely people. But their culture is different. You can only talk on the phone to the guy whose job it is is to talk on the phone.

"May I speak with the developer?"
"No."

Are you trying to put the guy whose job it is to talk to you out of a job?

Also

I work with a junior "Bangalorian". I ask "Please challenge and question what I'm doing: I may be completely wrong!"

"No, that's not my role. I will learn from you, but it would be disrespectful to challenge you."
 

XP and Agile?

XP focuses on code development. Agile is an overarching term that includes XP

"Extreme Programming is a discipline of software development based on values of simplicity, communication, feedback, and courage. It works by bringing the whole team together in the presence of simple practices, with enough feedback to enable the team to see where they are and to tune the practices to their unique situation. www.xprogramming.com"

XP is about:

Most of all, it is fun!

Remember: "Do the simplest thing that could possibly work".

XP focuses on is getting code produced. Not so much the team organisation. And really not the not larger scope of teams of teams. Agile is more the interaction of architecture of teams and team structure.

Minimum, but wholly adequate, testing.

Scenario based testing, unit testing is very developer centred. This is a quality team. (That is they focus on quality.) How do you extend this to the rest of the business?

(this needs fleshing out.)

Small team or a team of teams?

Division of roles. Small team – you do everything. Scaling to a large project individuals take on roles.
Some roles will be hired specialists. Tight defined roles "you're hired to do this."– some roles can be relaxed – more agile –

Segmentation of the projects into several teams over different time-zones.

How do you pull together 400 people over different times zones into a war room?

Agile Futures… remote pair programming.

10 – 15 seconds for a "stand-up"

Rapid prototype

A rapid prototype is throw away code. It has no unit tests. Do not confuse with preview releases.

Why .NET is productive?

Tools will always lag the techniques. But they're always catching up!

Agile and developer motivation

I'm a developer. I'm working on a project. When have I finished? When I think I'm finished? No - when the customer says so.
But I don't want to be lumbered with on going support over the years as I'm the one that knows the system. I don't want to be lumbered. When I'm done, I really am job. This is a job satisfaction issue. I want to move on.

The business case for Agile

You must make the business case – otherwise it will only be a pilot, and not be adopted.

Business cases include:

Agile in the business

Overarching view: The testers; the architect; the business analysts.

You may be a developer at an organisation that lacks quality business analysts. A marketing guy comes up with a pricing plan for a series of products - but there's no structure - no clear and consistent rules for upgrades. No prizes for guessing who has to step in and assume the business role!

You can't plan everything but you have to do the best possible. The product planning must exist – marketing, sales preparation, preview management must be orchestrated an be in step with the code development. This is a business responsibility.

Documentation

Document and rationalise the following steps:

User stories. -> specs (UML) -> architecture spec -> feature set.

Use a wiki to document what your team is doing. You must document. Write things down – especially if the team is in different rooms. Why
were decisions made. Traceability.

Have an issues list. (on a web site.) Open. All issues must be captured and be visible.

Yes it's an overhead. Be with it! (And you have to get on it to get off it.)

Must assume that some teams members will leave. (10%) Don't just have documentation hidden in code.

Keep the documents light but accurate, precise and exact.

Documents will be wrong if you go too deep. The code will be correct – so people won't use the documents.

Use the "EBOK" (engineering book of knowledge) from industry. What's learnt about non obvious problems: the failures and the solutions. Does not include the obvious - that would be clutter.

Use Groove.

Modelling the customer

Have a Customer proxy on team. Microsoft program managers are the customers' proxies.

Personas – a way of stereotyping a customer for your product. (The engineer, the mother… Power user, novice user, Regulators.) More involving than a use case actor.

Show something to the customer – not a bunch of documents. They've got to see it to believe it.

Developer / programmer must interact with the business. Must not be or feel "inadequate". Business must encourage the personal development of its engineers so that they can interact / understand the business.

Personal Experiences