Is my company agile? This is a question that plagues many software developers and testers -- and rightfully so. There is a lot of confusion in the software community on whether or not companies are developing in an environment that is truly agile, as they so often claim. And to add even more trouble to the mix, you would be hard pressed to find a company that isn't attempting to be agile or at least interested in it -- but even those "agile companies" are rarely what experts would consider "agile."
"How many of you are in an organization that is 'agile'?" Elizabeth Hendrickson, one of STAREast's keynote speakers, posed to an audience of nearly 300. The question prompted half or better of the attendees hands to rise with the claim that their organization is indeed agile or at least claiming to be. Hendrickson followed up being then asking, "How many of your organizations are agile by my definition?" Almost every hand went down.
The problem is rooted partially in miscommunication or misunderstanding within the industry in addition to the opaqueness of the word "agile." To be agile in one situation doesn't necessarily mean you'll be agile in the next situation even if the same procedures are followed, explained Hendrickson.
Agile is an understanding and a course of action that aligns requirements, processes, testing and development in an insightful order. One that should facilitate the needs of the project and be changeable as a project matures. But it is also acknowledgement
Agile by Hendrickson's definition is: a continuous stream of value with monthly intervals delivered all adding to a shippable final project.
"Having the whole team onboard from the get-go and testing throughout development is the start, and success is the finish line. There are numerous components that tie into the successful construction of software, says Hendrickson. "Teams should be building 'executable requirements' and developing a code structure that is malleable." Meaning if changes or additions become necessary, they can be added or subtracted without devastating an application.
As an example of what not to do, Hendrickson described a company that had brought her on as a consultant. They were gleaming with pride as they explained how 'agile' their organization had become. "They were using all of the terminology synonymous with the methodology, words like 'story,' 'collaboration' and the like, and that's when they pulled out the Gantt chart," a clear indication of how agile they were not, Hendrickson chuckled. They had successfully adopted the language of agile, but outside of that they were nothing more than a waterfall-based developer in an agile identity crisis.
This particular company had developed a plan of attack 18 months prior and had managed to release what they considered to be a finalized product within that timeline. But in their next project they were unable to repeat the process at the same level of success, and thus failed. "Agile" and "sustainable" are two words that are pretty useless in software development when separated. Hendrickson repeated several times throughout her presentation "it isn't done, until it really is done."
Keeping that in mind, teams must uncover a way to create the desired result and then streamline the process. Once this is accomplished and the results are sustainable, repeatable and scalable -- then a team has achieved agility in their development. That, plus the right level of automation in testing, can allow more time to focus on functionality, the interface and other features that would improve the application. Automation, when properly implemented, can free up testers for exploratory testing, a practice that Rob Sabourin said in a later session, "is overlooked far too often and for the wrong reasons."
There are four major areas of peril where agile development can flat line development initiatives. Hendrickson identified them as:
Ambiguity: Not knowing what your customers want.
Dependencies: Writing code or removing code that will damage the application.
Assumptions: Going with gut instincts versus involving others or asking the product owner.
Capacity: Having too much or too little of what is needed, whether that be information, staffing or anything that will retard progress or halt the creation and deployment of iterations.With the dangers exposed, here are some of the benefits and proven practices that agile can offer as explained by Hendrickson. "Again, there is no set way to be agile, what worked once may not work again. Agile is situation dependent," Hendrickson explained as she pulled up a slide entitled "8 Key Test Related Practices in Agile."
- ATDD - Acceptance Test-Driven Development
Getting testers in early, and commencing design and testing with the big picture always in mind, "how will this change or this addition affect the end result."
- TDP - Test Driven Practices
Make expectations explicit and drive out ambiguity. Align expectations, leverage documentation and develop and focus on executable results, do not digress from requirements unless the project can be improved by doing so (get product owner permission for this one).
- Regression Tests - Reduce latency and adjust project according to feedback. Fix defects as they are uncovered, but do not lose track of the initial test course.
- Collective Test Ownership - Since there are more than likely numerous team members responsible for designing applications, do not keep any aspect of that application from others. If you find a bug, share that discovery with the team, explain how you found it and how you solved it. Keeping the team up to speed and on the same page can accelerate the testing process and advance the collective wisdom of the team.
- Continuous Integration - When you find a bug fix it. Production should never come to a screeching stop, conquer the defect and share you solution methods with the team. Wikis are a great way to communicate ideas, issue discoveries and solutions to problems.
- Exploratory Testing - Implement this simultaneously with development of an application. Exploratory testing is a great way to familiarize yourself with the application, see how it reacts to situations it may never be exposed to, design tests you are more than certain will result in failure -- as the old saying goes, "what doesn't kill you, only makes you stronger" keep that in mind when writing exploratory tests. Getting and giving feedback is an excellent way to study the direction the product should be moving toward.
- Delivery Rehearsal - Even if an application passes all tests, provides a proven positive user experience, is virtually free of defects and seems ready to make it to the marketplace – STOP. Some of the worst failures come from launching a product prematurely. Testing can't always predict how a live application will respond to various input. Rehearsing delivery is a practice no team should skip it gives valuable insight into how the public will respond to the application, how it will do performance-wise and how much load it can endure. Break it sooner than later.
Hendrickson reinforced the importance of breaking applications early and often many times throughout the keynote. "You should try and break your application early in the game you have more time to repair it." By identifying the breaking point of applications will allow you opportunities to reinforce weak spots, thus making it more robust and improving it along the way.
Developers who take pride in having their code described as Rube Goldbergian be shunned. Complex, dependent and in soluble code is never something to take pride in.