The Agile Tribe

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.

Advertisements
Leave a comment »

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.

Read the rest of this entry »

2 Comments »

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.

1 Comment »

The Evolution of Test Driven Developers

Author: Peter Sellars (Reprinted with thanks to Peter)

Evolution

Test Driven Development (TDD) since its rediscovery by Kent Beck in the early noughties has led to an evolution in the information technology developers of our species. So where on the test driven developer evolutionary tree do you or your developer kind sit?
Read the rest of this entry »

Leave a comment »

The Agile Journey – a Testing Experience!

Author: Kate Ellery

It’s quite hard to believe that a couple of years ago we were thinking “what’s this new fandangle ‘Agile’ thing they’re trying to push on us?”!!! And how far we have come since. Ask anyone in the team now if they’d ever go back to traditional waterfall projects… boy, if looks could kill!

In testing, we have certainly had many challenges. And we’re still perfecting some of our processes and tools, but looking back, we have come a long way since Agile was an unknown phenomenon!

Areas of Vast Improvement

  • Testers are being involved at the start of projects, instead of coming in when the first iteration is starting;
  • Acceptance criteria is being written against user stories by the entire team (often this was written solely by our Business Analysts), ensuring a common (and accurate) understanding of each story;
  • Collaboration and communication with Business Analysts and Developers has greatly improved, with all team members taking accountability for project tasks;
  • New automated testing processes – what we are actually automating, where we are automating (UI, functional code, shared services), and the tools we use;
  • Co-location – project teams seated together to encourage active collaboration within teams, ensuring any issues or changes are communicated to all as they happen, rather than finding out about them too late down the track;
  • We find that fewer defects are logged, due to the acceptance criteria being used for unit testing – the story must pass this criteria before the card moving to ‘in testing’.

However, this does not mean that we are perfect (yet!). There are some areas where we still struggle. We find the monthly brown bag videoconference sessions with other testing teams around the company beneficial to discuss some of our issues, and learn from others’ experiences.

Areas where we still face Challenges (with a capital “C”)

  • Time – fitting all the testing tasks into each iteration; the main tasks being – test execution (system, functional, integration & regression testing across several environments), planning for the next sprint, automated testing;
  • Meetings meetings meetings!– daily stand-ups, showcases, retrospectives, planning sessions – all very important, but they all take up our “maker’s time”;
    and
  • Getting one project finished before the next starts – we have a 6 week warranty period where the project team supports any production issues, which can eat into the new project tasks.

On the whole though, we all enjoy Agile and our testing team has become a busier, but happier team who are more supportive to each other, as well as supporting other roles in and outsdie the core team. We also feel more appreciated by our team members, as there is a better understanding of what each role does within each project which has resulted in a greater respect for each other as well.

3 Comments »

Opening up an Agile window to let opportunity fly in – co-locating SMEs

Author: Cara Talbot

In my organisational experience to date the level of Subject Matter Expert (SME)’s co-location and engagement has strengthened from project to project. Thinking of how things were only a few years ago compared to our current state, there is just no comparison.

One project team’s perspective
We (my project team and I) have a current Project Owner and SME who both attend 95% of our daily standups – between them attendance is around 99%. We have a Programme Owner who, without invitation, has jumped onto our build environment to play with our online claims prototype, and then emailed the team with several suggestions and enhancements. 66% of the members of our Steering Committee attend 100% of our showcases.

Our Project Owner is such an advocate of the project that she has voluntarily presented work to date to various Managers and Executives in addition to and outside of our scheduled showcases and usability sessions. Sometimes this has been arranged without mentioning it to the rest of the team, which has presented interesting results when we’ve been testing and deploying – but hey, the enthusiasm and support from her of the technical team is to be commended! The team feels valued and by default collaborates more directly with her and other SMEs and so the ‘meeting of the minds’ is further strengthened.

We still have a ways to go, but how have we got to where we are? Often SMEs want to see results before they’ll provide buy in, so we can probably all talk of experiences of the chicken and egg scenario of how we can prove their co-location on a project will provide dividends prior to having them co-locate with us!

Keys and challenges to success
I can’t speak for other projects however for us it’s been, I think successful, largely due to seizing any opportunity to engage SMEs in value added Agile activities, so you can quickly turn around and demonstrate the results. We lost our Business Analyst recently (to our Sydney office. Ahem.) and had a lag time prior to having a new recruit join the team.

In the interim we had a half share of another Business Analyst who was also working on the support team. We therefore had a desk free, in the team space, for a half day every day. Our project owner agreed with our proposal that in providing a dedicated SME to cover this half day with the team, we could maintain progress during a vital period of development (beginning of sprint 3). Team velocity dipped slightly during this iteration as you’d expect with resource interruptions, handover and new arrivals getting up so speed, however by the end of sprint 4 our velocity had jumped by 13% compared to our average to date at that time, and a whopping 30% increase from our dip in sprint 3.

Part of that jump was also reflected in the drop in change requests coming across, although I could also suggest that that having a co-located SME seeing Agile development ‘in the raw’ provided a unique insight much more quickly in terms of understanding the impact that decisions can make on changes – the SME himself referred constantly to our focussing question (relating it to whether the change requests were adding value to the project/end user) … in addition, to turning around decisions of what was IN (and therefore what was OUT) much more quickly.

A genuine partnership has formed
Our project team is now back to being fully resourced, so logically we could have lost our SME … however, he still spends every morning sitting with the team, and helping out when needed.

2 Comments »

Teaching an old dog new tricks – Trick No. 3

Author: Nic Woollett

As part of our ongoing Agile journey in the mainframe/legacy environment, Acceptance testing is next in our list of our three ‘tricks’.

Acceptance testing was another big change to the way we normally operate in a mainframe/legacy environment. Acceptance testing was fully automated by using scripts: scripts run for each day to perform online maintenance, create files for the batch and then to validate the data post update. We actually developed a new scripting tool that enabled the testers to create test scenarios in a easy to use interface. The scripting tool then build executable scripts from the tester generated test scenarios.

When using scripts we required a testing region that could be restored back to a base point for each acceptance test run. When a test is built it will be run in every acceptance cycle thereafter – ensuring constant regression testing. Again, this offers a level of robustness above the standard testing approach where after a test is performed & accepted it is ticked off & (more often that not) forgotten.

Summary

Despite some initial scepticism that Agile could not work on a purely mainframe project – what with moving targets, short iterations and aggressive delivery times – we agreed from the start that we would stick as closely as possible to pure Agile. Whilst we are not LIVE yet I don’t think we would be as far along as we are now under waterfall and I believe the product we install will be much more robust under Agile.

What I learnt:

Formal system and user testing have both proven to be ideal subjects for automation.

1 Comment »

Teaching an old dog new tricks – Trick No. 2

Author: Nic Woollett

This blog is the second part of what we have learnt as mainframe/legacy developers while adhering as closely as possible to pure Agile principles. In order to do this we have tried to make a series of fundamental changes to how we operate.

So the second trick we have used on our Agile journey relates to Build and Unit Testing.

This was where the biggest shift came in our mindset as mainframe legal programmers. With iterative development you have to have repeatable testing – otherwise you’ll be stuck in an endless cycle of regression testing. Also, locating or manipulating test data can be a labour intensive process and in any case. Very rarely is all logic in the program tested.

A program could be changed in multiple stories and within each story only the changed portion of the program should require to be tested – regression testing should be automated. So, for our project we needed to:

  • Take away the need to locate/configure test data for each code change
  • Automate regression testing
  • Be able to target specific code to test
  • Make every test easily repeatable.

We did this by building a unit test framework – the first and probably only one in existence for Hogan. The framework consists of various tools and utilities that we developed for the Agile process. Broadly, each program requires a test program to drive the unit testing of this program. When run in the test framework the program can be tested in isolation and it requires no specific environment data – such as files or databases. The program can be tested over and over without the need for any user intervention.

The test framework (named the HUTF – Hogan Unit Test Framework) is now at the tried and trusted level and whilst initially it adds to the development time, when a developer is conversant with the tools they should be able to code and unit test much more efficiently. We also automated unit testing – a daily run was set-up to test all the test cases – a list that grows with each story. A report is generated and should any test fail an email is sent to the development team highlighting the failure(s).

What I learnt:

Developers spend too much time doing user acceptance testing under the name of unit testing. Using a test framework greatly cuts unit testing time allowing developers to do more developing.

Leave a comment »

Teaching an old dog new tricks – Trick No. 1

Author: Nic Woollett

I’m currently working on an in-sourcing project that involves only mainframe legacy systems. We’re attempting to stick as closely as possible to pure Agile principles. To get the most out of Agile we had to make a series of fundamental changes to how we (mainframe legacy programmers) operate.

Our approach took three parts:

The first of these was – Story elaboration

This was interesting – not using the waterfall method of waiting for fully described business requirements was initially a challenge. Developers were required to be fully involved in the elaboration process & this lead to a greater understanding of our business needs. It was a fundamental shift from “tell me what you want and I’ll build it” mentality.

It was quickly realised that we weren’t going to get the full story fleshed out in one elaboration session so the mentality of “build and show” was encouraged. This is iterative development within iterative development! It’s much better to be able to show the team something than theorise. After a few tweaks here and there the story is completed to everyone’s satisfaction – that renders the old waterfall post-implementation complaint of “that’s what I asked for but not what I wanted!” moot. After a while a common understanding takes over and (as a developer) you start to know what the business will want.

What I learnt:

I don’t always know what’s best for the customer and the customer doesn’t always know what they want. The best result comes from a show and tell style collaboration and co-location is a must.

1 Comment »

Mental Note: Co-location implies dedicated resources

Author: Andy Marks

For some people, co-location is a non-negotiable aspect for successful Agile teams. Yet sometimes barriers to having an entire team sit together come from somewhat unexpected quarters. For example:

I’m currently a tester working on three different projects. Each of the projects are on the same floor. There is a strong desire to co-locate teams to improve collaboration and communication.

But which project do I sit with:

  • The most important?
  • The one closest to delivery?
  • The most challenged?
  • The team I like working with the most?
  • The team with the least testing resource?
  • Do I time share – 33.3% time each day per project?

And the most important questions to answer: what is the root cause of the problems? The impracticalities of co-location? Or the problems with multi-tasking?

1 Comment »