Book Review – Agile Testing: A Practical Guide for Testers and Agile Teams
Posted on January 11, 2010 Leave a Comment
To date there is a lot of Agile literature focussing on development. So it was refreshing to see a book focusing on Agile Testing.
Agile methods have transformed the way we do testing and the role of the tester. Testing up front is a big mind-shift change for testers and management. Agile Testing: A Practical Guide for Testers and Agile Teams provides a good coverage of the issues testers face when they move from waterfall to agile from tools and metrics to mind-set, automation, roles and processes.
Littered throughout the book are “Lisa’s Story” and “Janet’s Story” – small snippets of real life Agile Testing war stories experienced by the authors which give you insight into ways testing was approached in relation to an agile project. There is a good mixture of high level concepts and guidance and lower level details.
The book identifies 7 Key Success Factors for successful agile testing (in order of importance):
- Use the Whole-Team Approach
- Adopt an Agile Testing Mind-Set.
(An agile testing attitude is a proactive, creative, open to new ideas, and willing to take on any task.) - Automate Regression Testing
- Provide and Obtain Feedback
- Build a Foundation of Core Practices
a. Continuous Integration
b. Test Environment
(Available and one you can control)
c. Manage Technical Debt
d. Working Incrementally
e. Coding and Testing Are Part of the One Process
f. Synergy between Practices - Collaborate with Customers
- Look at the Big Picture
I think testers new to agile will gain a lot by reading Section 5 – An Iteration in the Life of a Tester (Chapters 15-20) where testers can get a feel for what they would be doing throughout the agile development lifecycle. It explains the steps and activities testers do starting with planning releases and iterations to what happens daily throughout an iteration and then ending the iteration by delivering new features and finding ways for the team to improve the process.
Agile Testing : A Practical Guide for Testers and Agile Teams is the most comprehensive book on agile testing that is currently available. Even if you are not a tester, the book contains some useful information for other team members such as developers.
Building quality-in and Quality Assurance is a culture of an agile team and this book will put a tester on the path of the cultural shift for the better.
Share this:
Santa Adopts Agile
Posted on December 22, 2009 Leave a Comment
Thanks to a colleague for passing on the below article – a nice bent on Santa adopting Agile….and a nice marketing plug by Bright Green Projects.
Santa Claus CSM – Adopts Agile for the new decade
Santa Claus and his team of hard working elves are the latest high profile team to adopt an Agile Approach. They are believed to be the first large scale team to do so, within the Arctic Circle.
In a recent interview, Mr. Claus said “I’ve been working with this structured, heavily documented, big-bang approach for hundreds of years now – I didn’t know any better. As of 2010 – the North Pole will be Agile. Our first iteration will be delivered 25th JANUARY.”
Santa wants to not only give to children, but also to the Agile Community. He has shared the following for us all to learn from;
- The workshop builds toys based on a long list of children “who have been naughty or nice”. This list is in the order that Santa receives requests – his first task will be to prioritize this list. The most important children, such as those of celebrities, politicians or wealthy bankers will be at the top of the list.
- Santa will get out of the workshop, stop telling the elves what to do and encourage them to self manage.
- Rather than spending the entire year working alone in the North Pole, with a single delivery on 25TH DECEMBER, Santa will adopt an iterative approach with a deliverable on the 25th OF EACH MONTH.
- The most important children will be presented with their gifts on 25th JANUARY. If they are unhappy with what they receive, Santa will bring the gifts back to the workshop for rework. The rework will be prioritized against the backlog of other gifts.
- Not everyone is going to win. Given the high amount of rework expected from the “important” children, it is likely that those children towards the bottom of Santa’s List will not receive gifts every year. Santa sees this sacrifice as worthwhile, given the most important children will always be happy.
- Even though Santa will prioritize and ultimately own the “list”, the Elves will identify how much they can build each month and allocate tasks to each other independently of Santa.
- Gifts will only be considered “done” when they are built, tested, wrapped and the delivery method clearly defined.
- Children need to move away from heavily documenting their wish lists and make the time for a face-to-face conversation with Santa. Santa will now accept visitors to the North Pole all year and will also make himself available using video conferencing facilities.
- Bright Green Projects will be used by Santa, Mrs Claus, The Elves and Reindeer as their Agile Project Management Tool – this simple, web based tool will allow Santa and the team to collaborate and work together. As it is web based, it will allow him to more easily achieve his ultimate goal of moving to a warmer climate with Mrs. Claus and outsourcing the development process to an offshore team.
- Rudolph will be the Scrum Master, so long the other Reindeer promise to no longer “laugh and call him names”.
Share this:
Traditional Project Management Role on a Scrum Project
Posted on November 12, 2009 Leave a Comment
A “good read” article on Agile Journal, An Agile PM Isn’t What You Think Sub-Head: Where Does Traditional Project Management Fit in an Agile Project Using Scrum
There is always considerable discussion about the role of the Traditional Project Manager on an Agile Scrum Project and this article describes it very well.
In the end, Scrum does not prescribe where the individual currently serving as project manager should go in a Scrum project, only with whom the project management responsibilities lie and, as such, organizations should not assume that project managers always belong in a particular Scrum role.
[Edit 16 Nov 2009]
In another article 10 things a PM needs to know about Agile, the authors go as far as stating
There is no PM role in Agile
Whilst there is no single person performing the role of a PM, the elements and responsibilities of the traditional PM are performed by all the people on an Agile team.
I thought the following statement is quite true
“but who is going to chase them up if they don’t get their work done on time!?” In reality, this is more a fear than a real risk.
Ultimately, organisations and management need to trust individuals and teams to do their work – that’s why they hired them in the first place.
Share this:
Agile Australia 2009 Conference Report
Posted on October 22, 2009 1 Comment
I had the pleasure to attend Australia’s inaugural Agile Conference in Sydney supported by the Agile Alliance. It was a 2 day event on 15-16 October. Being the first Agile Conference in Australia, the key theme centered around Agile Adoption and how companies have adopted Agile; Why companies have adopted agile; and Issues and Challenges faced by companies in their adoption of Agile.
It was a very good conference with the ability to network and share ideas with other people during the breaks who are also working on their Agile adoption in their own companies. I have taken some key messages from the conference to help with the Agile adoption initiatives I am working on within HP Enterprise Services. I am already looking forward to next year’s event.
One of the more inspiring session I attended was the keynote on the 2nd day, Increasing Business value through simplicity (Lean and Agile) by Jeff Smith, CIO of Suncorp. Jeff provided the Executive sponsorship and the vision for “Living Agile” as a way to infuse organisational simplicty into the DNA of Suncorp through the introduction of Agile and Lean principles and methodologies. Any organisation would benefit having an Executive like Jeff to help drive their Agile adoption. I highly recommend you watching this inspiring video!!
The other sessions I attended with some key summaries:
DAY 1
- Panel – The journey towards the Agile enterprise; discussion on the Agile adoption journey by the respective panalist’s organisation.
- The journey needs active executive support which permeates through the enterprise.
- “Agile is about teams doing extraordinary things with ordinary people”.
- 12 Agile Adoption failure modes (Keynote Day 1) by Jean Tabaka, Rally Software; based on her experience it outlines that Agile does not fail. It is the Agile adoption mode that fails. Organisations need to stop the denial that waterfall is really deliverying value. Most of the 12 points are quite common when adopting Agile (yes, I have experienced some of it):
- Checkbook commitment doesn’t support organisational change management. Executives provide checkbook commitment to Agile without actually supporting the Agile adoption (unengaged). Same metrics are used and it continues the illiusion that software development is very deterministic.
- Culture doesn’t support change. Governance is Conformance; Standard of work is static; detailed documentation; PMO are enforcers.
- Do not have retrospectives. Or they are done, but actions that are identified are ignored or there is no action.
- Infrastructure to support the team is ignored or inadequate and architecture becomes unstable.
- Lack of full planning participation. If the right people are not part of the planning you will not get the right commitment.
- No or too many product owners.
- Bad Scrum Masters. Scrum Masters that are Command and Control.
- Not having an onsite evangelist/coach at remote teams.
- Team lacking authority. Empowered teams amplify learning.
- Testing not pulled forward.
- Traditional performance appraisals that reward individual heroics.
- Revert to old ways of doing things. Change is hard.
- What’s it take to make an Agile transition? by Shane Hastie, Software Education; focuses on the premise that Agile is a culture, not a methodology. The talk examines the organisational, cultural and individual changes needed for a business to successfully embrace Agile.
- Panel – Waterfall is from Mars, Agile is from Venus; panel discussion centered around bridging understanding and communication between Waterfall organisations and Agile teams. I didn’t get too much out of this session.
- Taking the Leap of Faith by Mike Allen; this was a good presentation that described the Agile journey that was used to deliver a large application transformation program. It starts with hiring the right people, providing the right office environment (the organisation spent money to reorganise the office to be more collaborative), provide the proper training and use the right tools. The Program started off as waterfall, but being a large program there was a lot inertia to get the program moving so Agile was introduced – Agile gets you moving. You may move in the wrong direction, but that is ok. Agile gets you back on course quickly.
- Better Software Faster! by Michael Milewski; another presentation on how realestate.com.au started the Agile adoption journey. It all started with a pilot project.
- Bringing IT back from the brink by Nigel Dalton; discussion on how Lonely Planet’s IT department was not delivering and how it used Agile to transform their organisation and brought the IT department back from the brink. Nigel introduced “Watergile” – when you dangerously mix waterfall with Agile – “it’ll drive you mad”. It was interesting to hear how Agile is used in a non-IT context in their new guidebook product development.
- Panel – Distributed Agile; Distributed agile has challenges. Expect more travel and travel costs, but this is is offset by the long term benefits it brings. Despite the challenges, distributed Agile is better than waterfall for projects with changing requirements & uncertainty. Distributed Agile means you need to pay more attention to the challenges, but the Agile practices itself will help improve the challenges. e.g. through retrospectives. Going distributed, 3 of the 4 Agile Manifesto values are compromised.
Day 2
- Lean and Agile in the large – principles and experiences for large scale software development by Dave Thomas; this was a good presentation by Dave Thomas who was one of the authors of the Agile Manifesto and founding member of the Agile Alliance. This presentation is worth watching. One metaphor I liked:
Successful software development is about a winning culture
- Software is a team sport, & like team sports, practice, constructive peer feedback & coaching are essential.
- Winning teams need to implicitly know the moves of each player, as well as the movements of the team as a whole.
- The ultimate expression of process is a culture where building software is more like playing Jazz!! People just do it!!!
- Understanding just-in-time requirements to support Lean software development by Martin Kearns; content of this presentation is self-explanatory from the tile. I didn’t get too much out of this that I didn’t already know.
- Lean thinking for Lean times by Alan Beacham and Jason Yip; discussed how Kanban is used to manage workflow in Agile projects.
- The inter-sprint break by Simon Bristow; this presentation discussed the introduction of the inter-sprint break – a period between the end of the Scrum sprint and the beginning of the next. This concept was very similar to a previous project I have worked on and I would recommend introducing such a concept.
- Being Agile at the Google scale by Dhanji Prasanna; this was a very technical presentation with much of it not about Agile. It was interesting to note that Google do not follow a specific agile method (eg. Scrum, XP, DSDM, etc). Instead Google base the way they approach work on the Agile Manifesto value “Individuals and interactions over processes and tools”. Google also has a fundamental prinicple: “Maximising the amount of work…..NOT done. a.k.a. Simplicity.”
- Agile mistakes and how to avoid them by Rown Bunning; was very similar to Jean Tabaka’s keynote on Day 1 where Rowan outlined some of the common mistakes in adopting Agile. He presented the Agile Metaphor: “Agile development is like teenage sex. Only 10% who say they are doing it, are actually doing it. And those who are actually doing it, are doing it wrong.”
Share this:
Customers Should Be Part Of The Team
Posted on September 28, 2009 Leave a Comment
Source: Dilbert 21-Sep-2009
Dilbert cartoons are great because they poke humour in everyday working situations, and they wouldn’t be funny if they weren’t true. Too many times have I seen project teams in the situation above, including ones I have worked on.
Customers should be made part of the team. A goal in Agile is to have the customer collaborate with the team and a key role is the Product Owner. Together the team and customer work out what is needed in the user story (requirement), what is required to start the user story and what are the acceptance criteria to pass.
Communication between the customer and team occurs throughout the project and feedback is provided by the customer to the team often. By having the customer part of the team it helps the team maintain a state of productivity by remaining available to answer questions and further clarify acceptance criteria. Because the team and the customer work together to discuss the user story, there are no misunderstandings and situations in the above cartoon should rarely occur.
Share this:
How Pixar uses Agile like practices to make their movies
Posted on September 16, 2009 Leave a Comment
The Harvard Business Review has published an article on How Pixar Fosters Collective Creativity in making their movies. The link is only a summary to the full article (which is paid), but it does provide some insights on how Pixar approach their film making.
Building complex software systems is very different to making a blockbuster film, but one thing in common is the people behind it. The way Pixar approach their film making is very similar to Agile practices.
Pixar have cross functional teams – Pixar assembles cross-company teams and find people who’ll work effectively together.
Pixar incrementally build out the movie – Though it is incomplete, Pixar demonstrate the animation work daily to enable the team to communicate important points to the entire crew at once and get candid feedback.
Pixar has self-organising teams – They help the teams to solve issues and the teams are trusted to solve complex problems themselves. People are encourged to help each other produce their best work. Managers are not afraid to hear bad news and they do not micro-manage the team. It is interesting to note that the managers are
okay to walk into a meeting and be surprised.
Pixar is constantly learning and improving they way they work through retrospectives (they called it post-mortems).
Pixar asks post-mortem participants to list the top five things they’d do again and the top five things they wouldn’t do.
This way they can extract the most valuable lessons and constantly inspect and adapt the way they work.
Can you produce a blockbuster software system?
Share this:
Management’s Role on Agile Projects
Posted on August 20, 2009 Leave a Comment
Mark Levison has written an excellent post on How Can Management Contribute to an Agile Project?
His post nicely complements my previous posts on a similar topic.
Share this:
IT is never 100 percent at fault for any massive project
Posted on August 7, 2009 Leave a Comment
If you read my previous blog post on Executive Support For Agile Adoption, I described how management support is important.
This topic is tocuhed on in Thomas Wailgum’s recent article in the CIO.com [5 Aug 2009], After a Massive Tech Project Failure: What IT Can Expect. In his article he states –
IT is never 100 percent at fault for any massive project
Thomas’ statement is supported by the Chaos Report by The Standish Group whereby the top 10 reasons for project failures have nothing to do with Technology but more to do with business governance –
- Incomplete Requirements
- Lack of User Involvement
- Lack of Resources
- Unrealistic Expectations
- Lack of Executive Support
- Changing Requirements & Specifications
- Lack of Planning
- Didn’t Need It Any Longer
- Lack of IT Management
- Technology Illiteracy
Furthermore, the Chaos Report indicates that the three major reasons that a project will succeed are user involvement, executive management support, and a clear statement of requirements. There are other success criteria, but with these three elements in place, the chances of success are much greater.
Thomas’ article is not advocating agile (the word is only mentioned once). What is mentioned is a common theme – be pragmatic, provide common sense and be practical. Agile is pragmatic, common sense and practical. And the first step to adopting agile is to have an open mind to it. You can be skeptical about Agile, but remain open-minded.
CIOs who resist against changing implementation methods—holding firmly to the waterfall when agile is the best option—and killing projects and their careers
The advice for such massive undertakings, which CIOs and analysts talk up but many don’t follow, is practical: Think bite-sized project chunks and set proper expectations.
“For some reason,” he adds, “we haven’t learned as an IT industry about driving incremental planning and change, which, in my mind, would help to mitigate the high rises and high falls of project failures.”
Agile is about incremental planning and change. For example, Scrum is an Empirical Process Control whereby you exercise control through frequent inspection and adaptation. The idea is that you do some planning and then do what you planned, inspect what you did and then adapt your behaviour to improve on what you did. You are constantly going through cycles of learning and improving the way you work.
As part of this learning, we need to encourage our managers to –
embrace change and transparency—even if it hurts at first. “The corporate culture—the status quo—tends to be: ‘Everything’s good. We don’t talk about problems until they are near unrecoverable, because we know people don’t like bad news,'” ….. But there are always going to be problems—vendor issues, or architecture, compliance or performance problems.
Agile provides the framework to detect bad news early. However, as mentioned in my last blog entry “managers need the ability to hear unwelcome news and should it occur deal with this effectively” as IT is never 100 percent at fault.
Like any illness, the earlier the detection the better as a cure can be found and applied sooner. Leave it too late and the illness can be fatal and you inevitably end up doing the Death March.
Share this:
Executive Support For Agile Adoption
Posted on July 30, 2009 3 Comments
One of the biggest failure to adopt Agile is not having the right mindshift change. This mindshift change can be quite signficant for some. Agile methodologies are a paradigm shift from tranditional “monumental” waterfall methodologies.
Managers and organisational leaders have a key role in helping adopting and transitioning to agile and this starts with the right mindshift change. Esther Derby’s article, The Three Pillars of Executive Support for Agile Adoption outlines what is needed to succeed from managers. What underpins the management support for agile adoption is managers having the right agile mindset.
It can be very difficult for managers to let go of Gantt charts, specific milestones and commitment dates they are accustomed to. No matter that few projects actually meet those targets, managers fear how much worse it would be if the targets and schedule (no matter how unrealistic) did not exist at all.
Ultimately, it will take time to change the mindset and opinion of managers who have dug into their positions over years of working with projects that miss deadlines, deliver low quality, systems that don’t meet customer’s needs, and throw up change control walls.
The 3 points in Ester’s article are not that uncommon.
1. The Power of “No”
How many times do we hear “we have always done it this way”? Manager’s need to demonstrate, subscribe to and commit to the agile practices, values and pinciples and this means not allowing people to fall back into old habits. This includes removing organisational impediments.
It’s predictable that when there’s a new method, process, or policy, people will request exceptions so they can continue to do things the old way.
There will be challenges in adopting any new methodology that you are not experienced with. Adopting agile is no different and will take some time. This is where an experienced agile coach may come in handy to guide the project along to successfully apply agile principles, values and practices.
2. Address Systemic Issues
Ester describes 3 systemic issues.
Three common patterns that I see driving exceptions are technical debt, overstuffing the pipe, and misaligned reward structures.
……
No methodology can fix these issues. These are management problems, and it takes management to fix them. Without management attention to systemic issues, you will achieve incremental improvements, at best.
Not fixing these systemic issues, Ester rightly points out that this “will sow cynicism in the organization”.
Consequently, agile will be seen as a failure when in fact the cause is nothing to do with the process or methodology used but the lack of management’s ability to address systemic issues.
3. The Ability to Hear Unwelcome News
In the agile community we believe in transparency and visibility. Within HP (and EDS), there is training which educates us to operate ethically and with integrity. To do this teams should be transparent with their management. Likewise, management will need to be transparent with the customer. And this helps build trust with the customer.
Status reports where it goes from green, green, green, green, and then suddenly red should not happen. With focus on working software in small releases, agile methods provide transparency of progress. However, managers will need to have “the ability to hear unwelcome news” should it occur and deal with this effectively.
The four value statments in the Agile Manifesto, shows perferences we should take. Managers have a key role to play when it comes to “Customer collaboration over contract negotiation”. Managers need to set realistic expecations with the customer. Unrealistic expectations lead to shortcuts, continuous fire fighting, accumulation of technical debt, and ultimately delaying the project more.
Management often resort to adding more resources to an already late project thinking more people-power will solve the problem. Ironically as Fred Brooke coined in the book The Mythical Man Month the term Brooke’s Law – “adding manpower to a late software project makes it later”. Instead, Ester encourages managers to —
Take management action. Have the difficult conversations and make the difficult choices to reduce scope or extend the date.
Agile methods don’t provide a silver bullet that guarantees success and requires a lot of management support.
Managment support for agile adoption is not just applying lip service and saying “we will adopt agile”, but demonstration of on-going support. Skills are important, but having the right agile mindset is more important.
A lot of agile is common sense but without the right mindset adoption can be difficult and fraught with danger.
RSS - Posts
