The Agile Manifesto devalued planning to such a large extent that many agile projects find themselves descending into complete chaos. An easy first step towards reducing this chaos is to introduce visual modeling of sprint plans -- to help you better organize your user stories, tasks and epics.
The second step towards making agile work better happens when you realize that agile techniques such as scrum and kanban focus entirely on the production side, or manufacturing process of building software. While the production side is unquestionably important, there's another aspect to software development that often gets neglected -- and that is the architecture/design/requirements part of the spectrum, which ICONIX has been helping companies with for the last 30 years.
Finally, if you've adopted Test Driven Development, you're probably wrestling with a range of testing related issues such as developers skipping unit testing, and how to handle acceptance testing. If that's the case, you might consider adding a little bit of Design Driven Testing into the mix.
Are you finding that your experience with agile methods doesn't live up to the hype that your company bought into? Perhaps your burndown charts are burning up, or you're having trouble with test coverage? Is the situation critical, and you need some emergency help?
So, your agile development process has gone off the rails and there is a train wreck. Bodies are strewn all around, there are broken bones and people are bleeding everywhere. Some parts of your code are savable, and some have to be thrown away. You need to triage the situation and do damage control.
The most visible sign of a scrummtastically bug-infested piece of software is the obvious lack of scenario testing. This results from project management robotically following what Matt Stephens so aptly termed The Green Bar of Shangri-La. In other words, all the unit tests pass, so hit the Ship It button and go on to the next sprint. But it's obvious to anybody who tries to actually use the software that it's actually full of bugs. These would be your customers, who presumably buy your products and services with their hard-earned money. So you'd better do some scenario testing. But wait, you have no model of your scenarios. Che cosa fare?
In addition to scenario testing, you need to test your software against a set of requirements. This might seem to be obvious, but it often gets forgotten in the rush to be agile. Writing requirements down slows you down, don't you see? And testing to make sure they're all satisfied slows you down even more. You could be shipping three new bug-filled releases in the time it takes to verify the requirements for one release. And your clients all love you more for delivering three new bug-filled releases. Sure they do.
Finally, we all work more carefully under time pressure. And even more carefully when there is perpetual time pressure. Yep, all of that time pressure helps you deliver higher quality product. Bet on it. Never take the time to do it right the first time, when you can take even more time to get it wrong a second and third time.
Another telltale sign that the relentless-time-pressure-pulse of the scrum cycle is leading you into a danger zone is when your software begins to develop an increasingly "user-hostile" tone. It's part of the scrummtastic mindset that the users exist to serve the developers, by feeding them bug reports to be added to the perpetual backlog of new user stories that will then be burned-down by the development team. That mindset of burning down the user stories has a funny way of manifesting itself into software that's excessively difficult and unpleasant to use, for thousands or millions of users, in order to save a junior programmer 10 minutes of coding time.
For example, consider the following abuse case, encountered while attempting to publish a book:
Abuse Case: Enter tax information
The system displays the Tax Information Page, presenting a form for the user to fill out that includes the tax-ID number
The user enters their tax ID number XX-YYYYYYY and clicks Done
The system scans the form for illegal hyphens
The system detects an illegal hyphen and informs the user that they must enter a 9 digit number with no characters other than 0-9 The user removes the hyphen and clicks Done
If anybody had bothered to write this scenario down in this form before the code was written, somebody (I pray) would have asked the question "why don't we just remove the hyphens instead of tormenting the user?".
In the scrummtastic world, there's never time to do this simple review, and the users have to take it and like it. Until you get a competitor who decides not to abuse their users...then your customers leave your business for the competition. And you're left with the magazine articles about what a great success agile has been at your company.
Is your software process broken? Think about how long it would take a competent programmer to remove hyphens from a tax ID number by typing taxID = taxID.replace('-', ''); -- and think about how many users will be annoyed by having to re-enter their tax ID numbers because the programmer was too lazy to do it.
Or, to paraphrase JFK....Ask not what your users can do to you, ask what you can do to your users.
ICONIX is pleased to offer a new on-site Agile Triage workshop, specifically designed to help companies and projects who are struggling to implement agile techniques, and need emergency assistance. Agile Triage is certainly not for everyone (and can be easily avoided by an ICONIX UML JumpStart class early in the project's lifecycle). But if you answer "Yes" to more than two of the following questions, our Agile Triage workshop might be just what the doctor ordered.
Try our simple self-assessment test:
If you've answered YES to two or more of the above questions, than our Agile Triage workshop might be for you. If you've answered YES to 4 or more questions, call us immediately, before it's too late.
