Becoming agile without permission

Archive for June, 2017

Do you set goals for big projects?
Do you set goals for releases?
Do you set goals when you get behind?
Do you set goals for regular work?
Do you set goals to goals in emergencies?
Do you set goals for the team?
Do you set goals for the sprint?
Do you set goals for yourself?
Do you set goals for the day?
Do you set goals for the next activity?

Why not?

​Is setting goals an unconscious activity?

Why not?

​The “Waterfall” method has dominated the last 30 years of enterprise software development. The method prescribes a series of steps that, when used with the correct templates, provides developers with all the information they need to create good software. We measured “good” by how well the software reflected the documents. The goal was to make software development so that anyone could participate in the definition of software requirements.​

We got so tied to the process and templates that we forgot about ​the software. The software became a secondary output to all of the other documentation.  We got so tied to the processes and templates that our governance revolved around using the right templates and filling in the right fields, not creating good software. All of this emphasis on forms and fields produced a generation or three of people whose job was to fill in the fields.

Then we realized that there are better ways to create software, agile ways.

​The Agi​​le ways tossed out most of the process and templates and documents and forms and told people to think about the software. Think about what we do that provides the most value to actually creating and delivering software.

Problem is, we have people who have only be taught how to fill out forms, how to fill in the blanks. We don’t have people that ​have been taught how to think about what will provide value. H​​ow to think about value. How to develop strategies for delivering​ software incrementally. How to evaluate what really is the Minimal Viable Product.

Even many of the Scrum masters and Agile coaches, the keepers of the agile ways, do not know how to think. They teach user Stories as a form to be filled out,

“As a ___ I want ___ so that ___.”

They don’t teach that the blanks are there to get us to think and talk about the who’s, the what’s, and the why’s.  We concentrate on filling out the fields in JIRA because there are fields. We don’t question if they are useful. It’s there, it must be filled out. The tools can record and track time so that must be important, right?

We don’t think. We just fill in the blanks.