The Zen of Agile

Author: Colin McCririck

We don’t really do TDD, we are a long way from achieving continuous delivery and our low levels of test coverage make releases a nervous time, but we think we’re pretty good at Agile.

I was reflecting on what I had learnt in the past year and how agile my team had become.  Despite immaturity at some of the key agile practices, in 12 months we deployed 79 releases to production for an application that is now processing 2 million transactions a day and serving 5 lines of business, 45 products and 3,000 concurrent users.   We ran four major projects concurrently while supporting production on a single codebase.  2011 involved lots of hard work, a dose of good luck and some progress on our journey to be more agile.

So here are some things I learnt last year:

1. Speed.  Velocity is great, especially if you deploy to production often, because business benefits start rolling early.  Rapid delivery also builds confidence and trust in your delivery capability (with management and the business).  There is, however, a dark side.  Velocity for us has brought with it technical debt.  The business and project teams care less about this while projects are delivering but speak to any production support or maintenance team and quality and technical debt usually feature highly.  Getting the balance right is difficult.  Do you pay your credit card off every month or let the interest grow till you hit the card limit (there’s a reason banks set limits on credit cards – there’s a point of no return).  Lesson –Deliver things fast to build business trust and confidence – success breeds success.  Make sure someone champions quality and technical debt reduction.  Velocity rarely needs a champion because it’s simpler to understand gets its own momentum.
2. Quality.  If speed is not matched with repeatable testing capability then you’ve built technical debt because every change requires regression testing to give confidence that the production system won’t break.  Remember this is the same functionality we wanted to deliver fast to get early benefits – if changes break the system your benefits stop rolling a lot faster than your project took to get them rolling.  Building quality in is the best way of working.  Traditional projects have late testing cycles.  The culture of ‘develop functionality fast and get someone else to test it later’ (lets call it test separation) amplifies two problems.  The first is slow defect feedback cycles which raise costs and lowers quality.  Secondly, projects cut testing effort when schedules slip and deadlines are committed.  Test separation culture is strong and difficult to shift to a team owned test culture (BDD, ATDD, TDD, test automation ie team shared accountability for building quality in).  Don’t underestimate this.  This is particularly important as you scale.  A team of 8-10 TDD guns can do amazing things, but when you scale that to 150, you have different problems to solve (hiring 10 TDD guns won’t change the other 140 people).  Lesson – Invest in building quality in.  It’s cheaper and more effective long term.  For larger teams you need to build capability and apply change management to make it stick.
3. Scale.  Size matters.  Agile is easier with small teams of smart engaged people but so is waterfall.  Big organisations have momentum and it’s difficult to turn a big ship.  Beware lipstick on a pig (politics drives some people to put lipstick on their pigs and call them agile) – thankfully agile is pretty transparent and pigs with lipstick stand out if you’re willing to walk the floors and read a few story walls.  Scaling from 10 people to 100+ usually means you have a normal distribution curve of capability.  To counteract this you need a change program at multiple levels.  Examples include the shift from manual to automated testing and the changing role of BA’s, developers, testers but also decision making and business involvement.  Lesson – Walk the floors, use the transparency to reinforce the changes.  Be brave enough to declare pigs with lipstick as pigs.
4. Culture.  From a leadership perspective this is one of the most important.  Many people see Agile as a methodology or see technical views of practices like TDD.  From a leadership perspective I see a shift from hierarchical command and control to self empowered teams – the teams choose what stories get done next.  This is confronting to leaders who thrive on the power of control and followers who want to be told what to do.  But a culture where people collaborate to understand business priorities and work together to deliver them faster is very powerful.  Cultural change needs strong leadership but also needs the right attitude and adaptability of the people in the engine room.  Lesson – Be willing to try new things and make it safe to fail.  Educate business, technical leaders and project managers as well as the engine room.  Set expectations – not everyone will drink the kool-aid.
5. People.  Standups and retrospectives are easy to learn, TDD is hard (as is BDD).  Many TDD advocates probably disagree, but I’ve found this practice to be much more difficult to adopt at a large scale.  I think this is because it’s a mindset shift.  Arrogance plays a part but change resistance is a bigger component.  Why do I need to test a one line change to a 10 line class?  In an application with 500,000 lines of code no one knows how the whole thing behaves.  TDD combined with automated acceptance tests provides fast feedback (read higher quality and lower cost defect reduction) and confidence that changes can be deployed to production.  People who have relied on testers and testing stages of projects for years struggle to change to the mindset that testing happens at the beginning, should be automated and repeatable and is the whole teams accountability.  Lesson – people naturally resist change.  A learning culture still needs goals and measures to help guide and drive capability improvement.

In summary, do simpler agile practices first, build on successes, keep learning.  Some agile practices are hard (especially at larger scale) but also have greater benefits.  Build a learning culture.  To misquote a Zen saying, if you think you’ve achieved it, you haven’t.

The Quick and The Dead…………….

Author:David Greenless

In the ever changing world of IT it’s extremely important to stay on top of things.  To be successful at almost everything these days you need to ‘hit the ground running’.

It’s fair to say that the above is common understanding.  But what tasks do you undertake to achieve it?

It is especially important in the world of consulting… multiple projects, multiple clients, and an even greater need to avoid failure!

I think it’s even more important in the world of software testing consulting.  By nature we (software testing consultants) are called in towards the end of the project…

It may be behind schedule, or perhaps testing was an after thought (shock, horror… but it still happens).  Whatever the reason may be, it tends to happen quite frequently.  This leaves us very little time to gain the amount of knowledge required to introduce a successful quality control such as testing.  All of this and I haven’t even begun to think about entering an agile environment.

Does this make it even more important again?  By nature, true agile environments are fast paced so I would think it does.

Below is a small sample of the things I like to do which assist me to ‘get up to speed’ in a timeframe that suits the context and level of my engagement (in no particular order):

•  Exploration – I find this is key, especially when engaged at the analyst level.  I find it very handy to request access to the applications/s under test (even if read only to begin with) and just get in there and dig around.  Take a tour of the application/s and note key areas/function points as you go and try some of the more common scenarios or use cases.  This will give you a great understanding even if only visual.  There will be many occasions when you attend meetings, etc. where the participants are talking about the application/s and you’d be surprised how much easier it will be to follow the discussion if you can visualise the areas they are talking about.  Michael Bolton wrote a cracker of a blog here, (http://www.developsense.com/blog/2009/04/of-testing-tours-and-dashboards/) and also take a look at the comments, specifically Cem Kaner’s.

• Meetings – Schedule new ones, attend existing ones.  When you’re new to an organisation or a project you’ll normally find that introductory meetings are booked, however if not then book away!  Putting a face to a name is vital and will help you understand where you can go if you need a question answered (we can’t know it all unfortunately).  I also find it useful to attend existing meetings that would not normally be attended by your role.  Even if it is simply a one off in the first week or so, it will give you a greater level of understanding and a better appreciation of what others are facing.  This is often met with confusion by the meeting chair when requested, but nine times out of ten they will actually be all for it once explained.

• Interviews – This does depend greatly on the level of your engagement, however one on one interviews are a great way of getting individual perspectives on project progress, team morale, etc.  Ask each of the Test Analysts how they feel about the application or what they think the biggest benefit will be from the new system, etc, etc.  You’ll discover many differing opinions which will assist in guiding your approach.

• Reading – This one goes without saying.  On most occasions there will be hundreds of pages of reading… project documentation, organisational procedures, training, etc, etc.  Fitting all of this in is a big task.  Instead of simply reading everything I’ll usually ask the right person (whomever that may be) what I need to concentrate on, and what I can skim over.  Take a risk based approach like you would for testing.  We’ve all heard of exhaustive testing and how in real world contexts it’s not possible?  Well exhaustive reading isn’t either, not when the deadline is knocking on your door!

• Build Relationships – I cannot stress enough how important this is!  Everyone does this differently, and your focus needs to be different depending on the type of relationship you’re trying to build.  Maybe you need to get on the developers side because you can see straight away there are going to be a large amount of bugs, or you’re going to need their help in developing stubs… maybe the architect because they know the business and technology layout like the back of their hands and will be able to answer any question you may have.  Whatever the need, get in early and build!  If you can identify with the ‘go to’ person in the initial few weeks, then things will be much easier for you.

Agile and Lean in Construction

Author: Dr. Adrian Smith, Ennova

Large scale construction projects suffer from cost and time overruns that are typically a symptom of productivity problems and directly affect overall industry profitability. As a result, methodologies have been developed to reduce the risk of overruns and improve project outcomes.

A number of these methods are based upon Lean principles that focus on identifying value, eliminating waste and creating a smooth flow of materials, information and work.

Construction Productivity:
Studies [1] suggest that between 70% and 90% of projects exceed the original planned cost and that the overrun commonly varies between 50% and 100% of budget. Some well known examples of significant project overruns include:

• Sydney Opera House – Final cost was 15 times more than originally planned

• Channel Tunnel – Final cost was 80% more than originally planned

• Boston Arterial Tunnel – Final cost was 196% more than originally planned

How Many Dysfunctions Fit

Author: Graeme Robb
Once upon a time there was a team and a manager…
Something has to be changed about the way the team is working.
The management decide what changes should be made and do not consult the team.

The team suggest that the change isn’t perfect, and the management would be wise to consider a few risks and suggestions.

The risks are noted but the suggestions from the team are not considered, partly because the frustration felt by the team comes through as a little negative, but mostly because the decision has been made already and the project must move on.

The team are frustrated, and cautiously proceed with the changes, the considerations that were raised by the team have been “noted”.

The risks eventually become an issue, the team is frustrated, and attempt to raise the suggestions as before, but cannot conceal their increased frustration.

The management are also frustrated by the issue, but are perturbed by the teams frustration which is now distinctly unconstructive.

The management conclude that the biggest issue is with the team’s attitude, and not by the risks that were raised.

The management decide that they must step in to address this problem and something has to be changed about the way the team is working.

The management decide what changes should be made and do not consult the team………..

Dealing With Split Teams and Communication

Author: Jonathan Coleman

Today we implemented a blanket Ban on emails!

We have a situation where our team is split in between two locations.

That’s bad. To compound this, one location has developers, and another has testers.

(you can already see that this story may not be a happy one!)

The team is new at Agile.

There is a lack of trust between the individuals in the two locations of the team. This means that the team is unable to raise a bug without an immediate conflagration.

“That’s not a bug! You’re testing it wrong!”  “There’s no unit testing, we’re developing it wrong”.  “Show me the design documents”.  “BIG-LONG-EMAIL-RANT”

As a result the trust is being MURDERED via longwinded emails.

So in terms of Agile & Collaboration – it’s not great!

In the last two months we’ve been doing everything possible to help with the communication:

• We’ve travelled frequently.
• We’ve engaged in shuttle-negotiation.  Back and Forth
• We’ve setup video comms and instant messaging on the machines.
• We’ve had independant negotiators.
• We’ve encouraged use of phone over email
• Everyone’s guardedly nice when we’re in one space.. but the emails begin once we return to our homes.

We’ve seen that  unfortunately  – the email rocket wars STILL occur.

Three Truths

Three truths about human behaviour that project managers should just accept:

Author: Graeme Robb – Agile Coach

1 . Many people become shy when the group gets larger than 5 people

It’s easily tested: put a group of 10 people together and ask them to do something. You’ll see that only 2-3 of them will be really actively contributing.

Do a separate test with groups of 5 and you’ll see that almost everyone will be much more relaxed and contribute in the task.

The truth is that many people are shy, and will withdraw almost completely from larger groups.

Now, obviously this is a personality thing and varies from person to person, so it’s probably quite relevant in IT where the requirement for high attention to detail and technical mastery often is best done by people who are on the introverted side of the scale.

Mix in some cultural issues and this becomes a very serious consideration. This reduced participation translates into $$$$s, so, design your projects around small teams.

Safe to fail – Blame worthy or Praise worthy?

Author: Phil Abernathy

In the April 2011 issue of the Harvard Business review , Amy Edmonson , Professor of Leadership and Management at the Harvard Business review, has a great article on strategies for learning from failure.

It made me think of  how the Agile way of working looks at failure and how we learn from it . In Agile the ‘safe to fail’ mantra is often talked about and just as often abused in more ways than one.

Sometimes teams and people are blamed for failure and hence don’t feel safe, sometimes teams use the ‘safe to fail’ umbrella to not follow any procedure or agreed rules and just do what they want.

A ‘safe’ environment is essential for improvement and innovation, creativity and morale, the key ingredient to creativity and morale, the key ingredient to creating this safe environment is clarity of what types of failures are ‘safe’.

 

 

Agile, What's in a Name?

Author: Peter Koevari

In my years of software testing, I have seen the result of what can happen when  an unfair reputation is built on something, and in this case, Agile (cue star wars death march music).

Why is it that so many people in the IT industry want to drop their pens in a meeting, leap off their chairs and run screaming when they hear the name? Has Agile become “That which shall not be named?”

Luckily, I don’t just ask these questions… I do have a theory to share with you all, really.

It has become painfully apparent to me and many colleagues, that Agile has been used when projects want to run with little to no documentation, a free for all attitude, and have pretty much no Agile training whatsoever.

These projects then call themselves “Agile” or what I would call “The Empire” and inflict pain, fear, and doubt in the universe… oh sorry, project team.

Star wars references aside, this is a scary trend which paints Agile in a horrible light. I am going to tell you what those individuals and failed projects don’t want you to hear.

Audit) Why did your project Fail?

PM) Because it was Agile.

Real Story) Because it was poorly managed and we called it Agile to cover our weaknesses.

Agile becomes the excuse, it becomes an enabler for poorly managed projects to fly a banner that escapes them of the real responsibility that the project has failed and was mis-managed or badly run.

This may work to save the behind of the uneducated, but it has many horrible side effects.

1) People start thinking that a project which is Agile will always spell F.A.I.L.U.R.E.

2) People do not understand what true Agile is, and how great it can be for any project.

3) People begin to spread their FUD (Fear, uncertainty, doubt) of Agile to all of their colleagues.

Chaos ensues. Planets get blown up and… oh sorry, there I go with Star Wars again.

Okay, probably not as dramatic as the movies… but equally as damaging.

Luckily for us, there are answers… there is the truth, and we *can* handle the truth (A few good men reference for those of you who haven’t see the film)

1) Agile does not mean failure

2) Agile does not mean no documentation.

3) Agile is very structured

4) Agile, tailored to meet the needs to any project, does work.

So, how does someone fix these problems?

I would love to re-badge Agile to a new name, but that’s obviously not going to happen… sadly.

I can imagine that if we called Agile something new, “The Rebellion”, people would flock to it, learn it, and not be so afraid of it in general. Then they would realise that it really does work.

There is no silver bullet here, but I entice you to ask questions in the next meeting that people roll their eyes or run in terror at the mention of the word Agile.

Ask them if they have had any training in Agile (Agile Academy can assist them with that). Ask them if they have had any experience with Agile.

What’s also important is to keep ourselves as professionals at the forefront of knowledge by following blogs related to Agile and our roles and sharing what we have learned.

Wouldn’t you know it… collaboration and sharing are just some of the principles of Agile.

The path to Agile

Author: Susan Akers

 Two of the most common questions I get asked as the Agile Academy Advisor are:

“How can I start my Agile journey? 

What type of training can I get?” 

 So I thought perhaps it was about time that I put something together in one spot to make it easy for people to see a clear path ahead of them and feel confident in moving to an Agile way of working.  One way to see what training might be useful is to have a look at our role based Training Roadmap and then read the course overview to make sure that you have the necessary pre-requisites.  The roadmap shows the recommended courses and pathway.

The Agile Academy has also produced a number of artefacts to complement our training courses and give budding Agilists an opportunity to have open access to easy to understand material.  These include our Agile in Practice Help Sheets which cover a number of Agile practices and techniques.  Most of these also have a complementary video which explains more about how each of these techniques can be used. 

All the very best on your Agile journey.  Don’t be discouraged if your path becomes a little windy, there are many resources to guide you and if you have any questions at all around Agile or training please feel free to contact us directly.

What's your role in an Agile team?

Author: Susan Akers

 This is an issue that many people face working in an Agile team particularly those in the role of Project Managers or Iteration Managers. 

Common questions around these two roles can be – 

• Are they the same role?
• Should the Iteration Manager just be someone from the team?
• How much time should be spent on being an IM? Full-time/part-time?

To help answer these questions and more, the Agile Academy has produced yet another handy Agile in Practice Help Sheet on Agile Team Roles and an accompanying video of the same name for those who want a bit more information about the difference between being a Project Manager and Iteration Manager; as well as seeing what other roles should be part of the Core Team and Extended Team.