Has “Agile” jumped the shark so to speak?! Let’s discuss.

Introduction
This is one of three in-depth articles I have written about the software development lifecycle and popular methodologies applied to that such as Agile and Waterfall. Why were they developed and introduced? Are organizations implementing it because they were told they should? Are they getting something out of it or is all or parts of it just a waste of time?
Key point – Processes should be lean and contribute to efficiency and productivity for the company, not waste valuable time and resources.

What is Agile?
Agile is a software development concept (manifesto) which was created by a conference of developers in 2001 to address common issues found in the software development lifecycle (SDLC) which they felt impeded effective application/web development. Agile, in the manifesto, is a concept because it does not lay out any specific methodology, framework or process for how to implement it (which later Dave Thomas, one of the signers, felt was a mistake). The method and process are implied in the tenets and it’s up to the specific organization to determine the best way to implement it and how that fits in with their corporate culture. Subsequent to 2001 much has been tried and written about it in terms of what works and what doesn’t. Whole organizations, consultancies and tools have sprouted up to teach and implement “Agile” to companies who want to implement it or just jump on a bandwagon.

The Manifesto for Agile Software Development
It’s important at the start to note that the Manifesto for Agile Software Development (creators of the manifesto like Dave Thomas cringe at the turnaround of the phrase to “The Agile Manifesto” as that changes its meaning and intent) was a declaration of values and principles not an actual framework for implementation. The idea was that using a declaration, individuals and teams could create their own framework. What ended up happening was that Scrum became one of the most popular frameworks used and taught, and many of the terms from Scrum are used interchangeably when talking about Agile. In another article I will discuss differences between Agile/Scrum and Waterfall (which is better, when best to apply one over the other) and wonder if Agile/Scrum are dead now.

“Individuals and interactions over processes and tools”
For this article I wanted to go into details about one of the principles of Agile vs how it has been implemented in frameworks like Scrum, when does it work, where there are implementation failures, and variations on the implementation.

One of the tenets of the Agile manifesto states:
“Individuals and interactions over processes and tools”
Using the caveat at the end of the manifest as a whole:
“That is, while there is value in the items on the right, we value the items on the left more.”

Good Process Is Like a Streetlamp
One of the things I have heard and seen quite often in my career in the software development industry is that specifics like this get muddied. For example people tend to take it that “process” is bad and impedes application development. This is a misunderstanding of the manifesto principle stated above and what underpinnings there need to be in order to have a functioning and efficient Agile SDLC. Even if you don’t have a documented process and even if the steps that are taken to develop and ship software are informal, those steps that are taken are a process. Technically whatever steps are taken and assumed to be the way that something is done, even if it is modified from time to time, is a process. You cannot divorce process from getting anything done. In fact it could be argued that when you are not getting things done, that is, when you are not completing and shipping relatively bug free software in a timely manner, you lack a process and an effective one at that. Someone once said process is like the streetlamp, you can use it to help light your way or instead spend a lot of time running around in the dark.

The Daily Meeting or Stand Up
There are many parts of frameworks that are used to try and implement an Agile process as a whole (which ends up creating a methodology) that I can get into and write about and I probably will. Here however I wanted to talk about what is known as the “stand up” or “daily meeting”. This has been codified most commonly in the Scrum framework and set of processes.
If you believe that Scrum comes out of your organization’s values and principles along the lines of the Manifesto, then you are “doing” Agile.
A daily stand up meeting done well can be an effective tool in the SDLC.
More often than not, however, I have seen numerous examples of it becoming an inefficient and bloated time consuming meeting which subverts the original intention and creates waste and inefficiency in the project and organization.
Here are the problems, as I have seen them, and a number of solutions which could be implemented to fix it.

My first introduction to Agile
Like many people who have been in the IT business for a long time, I have worked for companies in a “Waterfall” methodology environment. The first time I worked on an Agile project was in 2006 where I was the software quality assurance lead. It was a small group of maybe 5 or 6 developers who were converting an old coal mining system to a new, more modern one which kept existing functionality and added numerous enhancements. In the early stages the lead architect told me they were going to use Agile and would have daily stand up meetings at 9:00am every morning. I was invited to attend but it was not mandatory. The idea was that the meeting would last no longer than 15 minutes and each person would take a turn telling what they did yesterday, what they planned to do today, and any roadblocks they encountered. And they literally stood up for the meeting in their cubicle area.

There was a project manager who generally did not attend this meeting (which follows the principle of the meeting) and while I went to a few in the early stages, for the most part I didn’t attend the meetings. There were several reasons I didn’t attend on a regular basis – one being that I was at the time also tasked with developing a change management process and had meetings and business related to that which was a priority, and often I was not in the office yet at that time. Even so however, not attending the meeting had no detraction from my ability to work effectively with the group. I would simply go and talk to them later in the morning or day as needed (individuals and interactions over processes). In addition, I had the development tools on my desktop and could get the latest code, run the application, review what was ready for testing, and proceed accordingly. Ultimately the developers were not concerned that I did not attend the meeting because to them it was for them to fulfill the three functions and get on with their day.

The Three Core Principles of the Daily Meeting
The projects I have worked on where Agile/Scrum was used and where the daily meeting was successful and effective followed the three core principles.
Projects which were troubled, inefficient, and did not deliver working and relatively bug free software in a timely manner often did not.
Additionally, other factors which come into play are when the meeting is held and how information is communicated for those who are unable to be at the meeting.
This brings me to the first part of the observations about the problems I have seen with these meetings. While not explicitly stated in the manifesto, a number of subsequent documents about this part of the process (link) states that the daily meetings should consist of whoever is around and that there may be members of the team who are unavailable at that time.

Therefore, effective daily meetings have three core components:

1. An understanding of who the participants are and why
2. A stated time limit for the meetings (and thus each individual)
3. Meeting topics are limited to the three core principles and anything else is taken offline to a separate meeting between the people affected.

Core Principle #1 – An understanding of who the participants are and why
Let’s start with the first principle – who the participants are and why.
Effective daily stand up meetings (even if they sit down around a table) are most effective when they consist simply of the developers (a self organizing team (another Agile principle)). A manager or managers could also attend but their role should be limited. Unless a manager or project manager is instrumental in leading the meeting. For example, in the Scrum framework, the meeting can be led by a project manager or “scrum master” who goes through the list of items currently in development using a projection or white board as visual aid. They may update items in the toolset like Jira in real time. Quality assurance testers can also attend but their attendance should not be mandatory as long as they have ways of getting and communicating the information they need with the developers.

Not knowing who the participants are and why muddies the waters
The projects I have worked on where the meetings are less effective are when more and more people from different disciplines are invited to attend. You have developers from other groups, managers of various kinds and from related or different groups, business analysts, product managers, marketing people. And all of these people are expected to give an update. You end up with a full conference room of people standing around the sides and out the door. The people who are standing are definitely going to be uncomfortable after fifteen minutes turns to 30 or 45.

The idea, I believe, of having all these other people in the meeting is to communicate information and ensure everyone knows what’s going on in each aspect of the product development areas.

The problems of course are that:

1. The meeting ends up taking a lot longer than intended,
2. The subject matter ends up being more along the lines of a general managerial status meeting and not the three Agile principles which are supposed to drive software development.
3. Some people take much longer to give their input and others just wanting to get out of there take far less than they might otherwise.
4.  Also numerous discussion items which should be taken out and offline end up taking place in the meeting.

The end result is that, besides being inefficient and the opposite of lean, the developers stuck in these meetings end up frustrated and disillusioned that they cannot be at their workstations programming and getting work done (which of course is not good for morale)!

What is the solution?
The solution is, of course, to get back to basics and have a daily meeting which does not have all the peripheral people. Just keep it to developers.

If you want or need to have a meeting with all those other people then by all means do so at another place and time and less often than on a daily basis.
Developers, while they for the most part understand the use and value of a daily meeting with other developers, don’t like meetings, and prefer to be left alone programming – doing what they consider to be real work. Most people don’t understand that developers need a long period of uninterrupted time to focus and hold everything in their head.

So where do business people and developers ideally interact during the day?
One of the manifesto principles states” “Business people and developers must work together daily throughout the project.” This is often mistaken to mean that business people should attend the daily standup. Additionally the term “Business people” is often mistakenly meant to mean internal business facing people like business analysts or product managers. It can mean those people if your organization wants to interpret it that way but its original intent was to mean the end users/consumers of the software. Often those people are customers/clients.

What is the ideal time to have non-Agile Status Meetings?
Based on anecdotal evidence from reading articles and having discussions with developers, they get the least amount of work done between 12:00pm and 3:00pm. Thus the ideal time to have those other group meetings is between 1:00pm and 3:00pm. Such a meeting would encompass not just developers and testers but business analysts, product managers, marketing people, project managers etc. The noon lunch hour provides a break and then holding meetings after that provides a transition time for programmers to digest and prepare for another period of extended focus after 2 or 3pm. And these other meetings should not take place more than once or twice a week with informal discussions taking place as needed.

A Case Study of a 20 Minute Noon Agile Stand Up Meeting
An example of having a noon standup meeting was discussed in the book “On Purpose: Delivering a Branded Customer Experience People Love” By Shaun Smith, Andy Milligan. They quote a technical director named John Patsvellas who says: “Our purpose and values manifest themselves on a day to day basis, habitually – because we value feedback and we talk to everyone and they feel happy to talk to us. There is a lot of engagement. For example, we have what I call an agile meeting at 12 noon every day. We have a stand-up meeting, we talk only about three things; every area and department – technical and manufacturing, logistics and planning – and they can say, ‘Here’s our priority for the day,’ ‘Here’s out sticking point for the day,’ ‘Here’s one of our successes from yesterday.’ We have that at 12 noon because people have had a chance to catch up with their day, it’s only 20 minutes and if we haven’t finished in 20 minutes, we get out. It’s not mandatory attendance. It is whoever wants to show up. It enables us to understand the priorities in a big (company) like this. We often circle back after the meeting and say, ‘Okay, let’s talk about your sticking point.’ ”

Core Principle #2 – A stated time limit for the meetings (and thus each individual)
To keep meetings on track, it can be agreed to “timebox” or create a time limit for the meeting. To set a time limit you need to calculate about how much time each person can have. For example if you allot one to two minutes per person and you have a five member team, that comes out to a meeting which is at about five to 10 minutes long. There does need to be some flexibility though because if there are roadblocks and they are relevant to discuss in the meeting, then you may need an additional five to 10 minutes on the whole. However if an issue is going to take more than two or three minutes to discuss, then it should be put into the “parking lot” and taken offline between the people involved.

Core Principle #3 – Meeting topics are limited to the three main principles and anything else is taken offline to a separate meeting between the people affected.

Here are the three main topics for discussion in an Agile stand up / daily meeting:

1. What I did or accomplished yesterday
2. What I plan to do or accomplish today
3. Any roadblocks I encountered

Any other topics or discussion or diversions which are not taken to the parking lot, risk putting the meeting’s time limit and scope (and thus its effectiveness) in jeopardy. There isn’t a whole lot more to say about this than what I already did in the discussion of the first principle.

Alternatives and Alterations of the Daily Meeting
More and more teams are distributed and therefore not all of the participants can meet face to face or at the time same time. Here are some examples of when and how daily meetings can occur with local or distributed teams.

Some teams only meet Monday through Thursday.
A team I worked on who met Monday through Thursday at 10:00am would accept status updates to the group via email if they were going to be late or absent or could participate over the phone.

I know someone who works as a developer on a distributed team based on California. He is on a daily phone call at 11:00am Mountain time every day which means that the meeting time is 10:00am on Pacific time, 1:00pm Eastern.

I know another developer who is part of a remote team which has only two to three (“stand-up”) meeting phone calls a week at 1:00pm Mountain time.

I read about a team which has “daily meetings” at 10:00am Eastern time and you are expected to attend in your time zone regardless of what time it is there. I disagree with this method and noted as a comment in this blog post that I used to run Global Change Advisory Board meetings and we rotated the time on a monthly basis so everyone could more fairly share the pain.

Too much time spent in unnecessary meetings, let’s do away with the meeting altogether!
How can you do away with meetings in the first place and is that even possible?
Why would you do that even if you have perfected the 15 minute meeting?
I guess you have to ask yourself is this meeting actually useful or are people just doing it in a rote fashion to satisfy that they are “doing Agile” or because the “Scrum master” and/or manager thinks it has to be done?
First off, unless you have a team with less than about seven people there is little chance you will be able to have an effective and disciplined meeting of fifteen minutes or less.
Second, if chances are, like many companies, your group is the one which throws in everyone and the kitchen sink, your meeting is filled with too many people and takes too long.

Meeting Virtualization
When I worked for a mining and manufacturing company, the Business Process Improvement group said that there were too many meetings and that there was a cost associated with the number of people in a meeting and the time spent in them. Before you go rolling your eyes at the “bean counters” let me explain. Money and time could be saved by “virtualizing” a lot of meetings and only having in person meetings when and where the issues merited it and then only with the affected people. I will go into detail about this in a separate article.

Virtual and Remote Work and Teams
With modern toolsets like Jira and Slack and other remote work collaborative tools, there fewer reasons why there needs to be an in person meeting in the first place. As long as everyone updates their status and tickets, then anyone looking should be able to know what’s going on at a glance.

This can work as long as the following are in place.

1. The team and the culture needs to be mature enough where people are going to know and do what is expected of them on a regular basis.
2. There needs to a product or project manager who will monitor that things are getting updated on a regular basis.
3. A certain amount of automation will help. You can have the three questions on an electronic form that gets completed by each person and they can tag whoever they need to meet with to discuss issues.

The Daily Meeting as a Management Tool vs Productivity Tool
I will also draw your attention to the article that Yegor Bugayenko, a programmer, writes a very interesting piece about “Daily Stand-Up Meetings Are a Good Tool for a Bad Manager”. It’s not written from the point of view of whether or not daily meetings can work or how to do them but that as a management tool, it is only “bad” managers who use them as a key management tool.

The reason I draw a distinction between a “Management” tool and a “Productivity” tool (but of course we can’t say they are all like that), is because often in my experience when a manager loves a tool and wants employees to use it (like Test Rail) that is because it is more from a data gathering and reporting perspective than any productivity benefits individual contributors might gain from it.

Conclusion
The daily / stand up meeting is part of a process even though it is an interaction. The “Agile manifesto” states that interaction is more important than process, therefore when or how the interaction occurs is less important than the fact that an interaction takes place. Therefore when the process and mechanics of the interaction take precedence, the interaction runs the risk of losing its usefulness and effectiveness. So while process itself is not inherently bad, not balancing things out and using it effectively means running the risk of “bad” outcomes.

The Agile daily / stand up meeting should be with specific people key to the development endeavor and who are around. Those that for whatever reason can’t make it should be given other options to interact/communicate the three items in other ways. They could call into the meeting, send an email to the core group, or use a designated toolset. Status reporting, which is separate from the daily development effort (and is more a management function), should be able to be derived from informal discussions, emails, chats, and whatever tool is being used to track pieces of work in the project.

This brings up the idea of alternative ways to track and report on all this especially with distributed teams who cannot be in the same office or attend a meeting at the same time. For example, a tool like Assembla offers the ability to track status. There should be a way to use a tool where everyone enters their information and can see it so everyone including management can have an understanding at any point in time where things stand. (But many of these things are for a separate discussion.)

Future discussion will include Agile vs Waterfall and is Agile even a worthwhile method to implement anymore.

What about you and your team? When does the meeting can take place?
What are common misperceptions which thwart the purpose of the meeting?
What are processes which support an Agile development methodology?
What are pitfalls and challenges that prevent an efficient and effective set of processes to guide a successful application development effort?

Comment down below with your thoughts!
Like and Share this article and Subscribe for future updates!