Agile and Scrum are Good.

AGILE and SCRUM "revisited"

In one of my original posts, I made it clear that I was NOT a fan of this so-called AGILE process. Since then, however; outside of the demands of that particular employer, I have had the opportunity to really learn and digest Agile. And in truth, I have changed my mind... Provided that in actual practice, AGILE, is what the group/teams/employer are - "AGILE"...

Let me say this, there are some very GOOD parts of AGILE development: User stories; iterative development; Backlog/backlog grooming; Acceptance Testing; Continuous Integration & Development; Scrum meetings; Pair Programming; Regular recurring team meetings with the stakeholders - to name those of which I am most familiar with, and; we did indeed practice at my last company.

Anyway, since then, I've reviewed AGILE from the Agile Alliance website, and now realize that - all of my previous issues with what was being called AGILE, were in fact, the mis-implementation of a few things which in fact, and truth, are NOT either AGILE best practices, nor actually AGILE in practice.

In summary, what they did WRONG included, that; my previous employer's approach to Agile and Scrum imposed a few things, which, by their very nature - were anything but PRODUCTIVE, and certainly NOT Agile, in the realm of real-world-reality.

Let me identify the worst of these things ...

WHAT THEY DID WRONG... and RIGHT ... and WRONG ...

For those who are interested, you should really go to agilealliance.org, and read all of this for yourself. One of the things my previous employer did NOT do, was to inform ANYONE that that website existed - at all. Nay, what they did was, create their OWN AGILE website, and populated it with their own definitions of pretty much EVERYTHING. Right off the bat, that was one of the "WRONGs". But, I mention this early, only, to make it clear that - if a

company is going to do AGILE development, and do AGILE as their "way", then; they need to DO AGILE as it is actually DEFINED, not as they "WOULD PREFER" that it be.

Anyway, among the things they did RIGHT, included, SPRINTS of a few weeks; SPRINT PLANNING and SPRINT RETROSPECTIVE; Backlog creation/maintenance/selection; these were things that they did do correctly - and - I and my peers found value in these things for the most part. Although, their idea of REVIEW was again, something that was done incorrectly. For they expected multiple teams, with virtually nothing to do with each other, to sit-and-share REVIEW meetings. In short, why would a NETWORKING TEAM, sit for as much as half the meeting, listening to a DATABASE TEAM talk about THEIR things, and visa versa, most particularly, when neither of these teams ACTUALLY DOES ANY WORK/PROJECTS TOGETHER - EVER.

My previous employer was doing this - repeatedly. It was a huge frustration for everyone involved. And, another point, it did not matter how much ANYONE in IT complained, the answer was - THIS IS AGILE - you will do it THIS WAY - or ELSE. And for more than 10-years, that is precisely what our teams did. We did it, as best as we could, in the way THEY TOLD US, was AGILE. Remember, we had no idea there was an AGILE WEBSITE at the time... We were told AGILE was only what was on the internal company AGILE website.

USER STORIES

As detailed by Mr. Mike Cohn at mountaingoatsoftware, "User stories are part of an agile approach that helps shift the focus from writing about requirements to talking about them. All agile user stories include a written sentence or two and, more importantly, a series of conversations about the desired functionality.

User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.

User stories are often written on index cards or sticky notes, stored in a shoe box, and arranged on walls or tables to facilitate planning and discussion. As such, they strongly shift the focus from writing about features to discussing them. In fact, these discussions are more important than whatever text is written."

I can assure you that this definition makes sense - and in truth - I completely agree with it. But, my previous employer's definition of a user story, was forced upon IT, from a Template, that was constructed by a nameless, faceless committee, which clearly had NO EXPERIENCE in SOFTWARE ENGINEERING, NETWORK ENGINEERING, nor any real world experience in IT.

It was 5-pages long - even when it was EMPTY.

Moreover, at this company, it took nothing less than 2-or-3-full days of effort to fill in one of these documents, then; by their own interpretation of AGILE, they would have us submit them for REVIEW, to a comittee - who - was only concerned that all "I's were DOTTED" and "T's CROSSED", AND NOT AT ALL, with the content of the User Story, nor with any of the purpose and functionality. We spent, most often, WEEKS, writing, reviewing, and tweaking "User Stories" - to fit a 5-page template, which did nothing to improve PRODUCTIVITY, SPEED, and QUALITY of deliveries.

This single practice - all by itself - made a task that should have taken, at most a few hours, or even a single day, require nothing less than 3-to-4-days, just to get STARTED on the next task that one might wish to accomplish, within a 2-week SPRINT. And this is among the many things they did NOT do right. According to the AGILE manifesto, and others; USER STORIES can be as simple as a STICKY NOTE that clearly identifies a NEED, CHANGE, and SOLUTION. Not a 5+page bureaucratic document that in itself, required reviews - merely to allow us to START work.

SCRUM MEETINGS

Scrum is a process framework used to manage product development and other knowledge work. Scrum is empirical in that it provides a means for teams to establish a hypothesis of how they think something works, try it out, reflect on the experience, and make the appropriate adjustments. That is, when the framework is used properly.

Scrum is structured in a way that allows teams to incorporate practices from other frameworks where they make sense for the team’s context. Scrum is best suited in the case where a cross functional team is working in a product development setting where there is a non trivial amount of work that lends itself to being split into more than one 2 - 4 week iteration.

Our bosses required our scrum meetings to involve MULTIPLE, UNRELATED TEAMS, not because we all had the same tasks, goals, and needs. In this instance, we were all working for the same CHAIN OF COMMAND. But, insofar as the work each team did, there was no connection WHAT SO EVER. We had different CLIENTS, different STAKE HOLDERS, different PRODUCT CHAINS, and different EVERYTHING. These meetings were supposed to last only an HOUR. But, by forcing 3-or-4 unrelated TEAMS to all attend the same SCRUM MEETINGS, it was all that everyone could do, just to VERY quickly INTRODUCE and sort-a-kind-a REVIEW what was going on in THEIR TEAM.

And keep in mind, the other teams in question, had to all SIT and LISTEN to each other, with teams that were involved in projects and client chains, which had no direct connection, interest, or NEED TO BE MEETING, other than, we all, ultimately reported to the same DIRECTOR or PRODUCT development arena.

Scrum meetings - YES. Forced merge/blending of unrelated teams in such meetings - NO.

SPRINTS and DELIVERIES

This is where the company really missed the mark. In essence, it is clear that a sprint is intended to create SOME KIND OF A DELIVERABLE. An it is clear from AGILE that the stakeholders of the need, all agree what a DELIVERABLE is. Not so at my previous company. The bosses wanted every sprint to END with an actual DELIVERY of a NEW WORKING PRODUCT or PRODUCT VERSION or PRODUCT ENHANCEMENT. In short, they REQUIRED each SPRINT to be a complete "soup-to-nuts" development cycle from concept to tested product. And it did not matter how much everyone pointed out that, your documentation AND review process - ALONE - requires several DAYS of each sprint. There is no WAY that a single SPRINT can be expected to be a PRODUCT or IMPROVEMENT "to production".

It did not matter how much, nor how often, we all tried to make it clear, this was not going to happen. At least, not for more than 3-years. And FINALLY, someone at the TOP listened, and allowed the TEAMs to define WHAT went into a SPRINT, and what constituted a DELIVERY for that SPRINT. But, for YEARs it was a huge struggle, just to get them to allow the ENGINEERING TEAMS to define what to deliver, and what to call COMPLETE with each sprint. Even AFTER that was done correctly, never did they relinquish the issue of the USER STORY that is 5-pages long. So, at that company, we had entire SPRINTS that were devoted to "actual get work done sprints" that followed, which were followed by SPRINTS that reviewed the backlog(s) and such...

ARE YOU READING this correctly? Yes.

You might wonder, how is it that anyone could MISS THE MARK so badly? Seriously, how could it be that anyone could NOT get AGILE more correct than what is being presented here, in this summary? There is something that AGILE does NOT address... And it should not be a problem, but; in that company, it was. And, it is something that AGILE should address - I believe, which is - in short:

BALANCE of WORKLOAD and MANPOWER

The largest single TRUTH at my last company, was; that over the course of several years, they kept reducing the number of PEOPLE in INFORMATION TECHNOLOGIES. But, the work loads did not diminish in anyway. In fact, they did INCREASE. When I STARTED with my previous employer, we had 30-people to work (roughly speaking) 10-to-12-projects at a time. Which overall is 2-or-3-people per project. It made sense. Somewhere early on, people LEFT or people were CUT. And, with the promise this was TEMPORARY, those who were left, were told - you need to pick up the SLACK for those who are now GONE.

Of course, in any situation, in any organization, there will be times when a few people come, and a few go, and for a few months, to perhaps a YEAR, others will have to PICK-UP-THE-SLACK. Most of us IT Professionals understand this, accept it, and have no issue what so ever - doing this.

The problem is, at this company, from the VERY TOP (EVP Level), starting in 2006, we were ALL told: No, we will NOT be replacing that person. That JOB is gone. You have to figure out how to make it work with (now) 9-people vs 10. Then 8-people vs. 9. Then 7, then 6, then 5, then 4...

And by the time 2011 rolled around, almost everyone left in IT, was doing the job of 3-or-4-people - all the time - EVERY SINGLE DAY. In other words, where once it was "12-systems with 24-people", you ended up with "12-systems with 5-people". And those who remained, were doing EVERYTHING. Design, Documentation, AIP (Application Infrastructure Provider) management, TESTING, DEPLOYMENT, and of course, SOFTWARE and NETWORK engineering.

And that is how you get SCRUM MEETINGS that cannot possibly cover EVERYTHING.

When there is a severe lack of BALANCE between WORKLOAD and MANPOWER, then there is virtually no way for ANYTHING - EVEN AGILE - to be EFFICIENT and PRODUCTIVE. Not on the large scale, not on the minute scale, not at all, ever. But that is precisely how things were for all of IT - for more than a decade. A company of more than 70,000-employees, supported by an IT staff of LESS than 3,000. When less than 4% of your entire workforce is ACTUALLY IT, and you are calling yourself a TECHNOLOGY COMPANY... There is a serious problem.

And that was why many things we struggled to continue to do - just didn't fit what they were telling us all was AGILE. Because, the way it came down from the leadership, was simply "Do more, with less, faster, and make it better".

All in spite of - the one TRUTH that AGILE does not address:

A lack of proper manpower.

CONCLUSION

I don't know if there was actually as much nefarious intent as we sometimes wondered and believed, but; without a doubt, my previous employer got some Agile things right, and also, some Agile things VERY, VERY, VERY WRONG. In those things that they did wrong, among the highest issues included, not listening to the employees, and not having enough people, to accomplish the tasks you desired and required.

As I mentioned at the start of this post... AGILE - yes. Now that I know more, and not merely what "they" told me, not was imposed upon me - I very much like AGILE. But, when we speak of Agile, let's do it RIGHT, and HONESTLY. Learn it from the authors, and those who ARE doing it right (start with https://www.scrumalliance.org/). And practice it RIGHT. Don't water it down, or "adjust it" to fit what you want to do "your own way".

Either you are AGILE in practice, or you are NOT. I now truly believe that, if learned and practiced as intended, and devised, AGILE is a sound methodology - and a very highly recommended practice, within any productive and positive situation and/or company. Bottom line is:

When done CORRECTLY … Agile and Scrum are Good