It is the fashionable thing to poo-poo Waterfall methodologies lately, but I am beginning to think that it is far too simplistic a view to say that you can’t know everything ahead of time. True, the classic Gantt Chart model with each activity planned to the hour, dependencies, and Critical Path *may be* overkill, but what is this chart really doing? It is saying that “these are things we need to do, and this is how we are going to try to do it.”

Agile, Kanban, Scrum all denote tasks. Some use sticky notes. Some use a backlog. The tasks are still there. What is missing is that long black .mpp bar that limits the amorphous black box of “Development”. Non-Waterfall approaches still execute tasks in order, but that order is defined as you go to an extent. In reality, every team member has what they know about the project and tasks in their mind, and they are doing mini Gantt charts in their head. Even if it is moment by moment, people plan. Nobody sits and just codes without a goal. Remember, you have plans to accomplish goals. You might say that the definition of a plan is it’s goal.

When nothing is known about an incipient effort, there is room and need for Agility. There is less room or need for Agility when the project is more cut and dry (“install MS Office” or “stand up Drupal in our dev environment”).

Point being, even “Agile” approaches involve planning. Just not as much, and not as far ahead, and not to the level of detail that an overzealous Business Analyst / Project Manager might do in their trusty .mpp. Seriously, I have seen some pretty detailed project plans, but I have not seen any that presume to know horrific levels of granularity. Those horrific granules are generally requirements, and they are valid in any effort. They tend to live somewhere else -wireframes, a functional spec, business rules, wherever that particular team puts that stuff.

People over process is a tenet of Agile. This is, apparently, to say that in “Waterfall” practices process trumps people. Everyone reading this knows that invariably any project, no matter how strong the Business Case or how vital the technical effort, there is someone in an office that can derail everything at whim. People are always over process. The trick is to adapt the process to the people and accommodate the people. All your stakeholders are important, and it is equally important to realize who has not been named a stakeholder yet has the ability to rock your world if they choose to.

Even something as sexy as Kanban is to some people; it is just people performing tasks in an organized fashion. What is new about this? It is Waterfall, diluted. The very discussion of Kanban and it’s amazing achievements in Japan is ceremony. Putting up the board is ceremony. Taking the cellophane off of the post-its is ceremony. Ceremony means nothing. You just don’t want to waste more time than you have to. You don’t want to say things like “muda” because nobody will know that you mean “waste” and you will be mudaing all over the place.  The little stickies are ceremony. Sprints are ceremony.

Any task that has been designated as a 4 day task will take 99 percent of developers 4 days to do. If they finish core functionality in one day, they will use the 3 extra to make it better. They build. And at the end of 4 days and continuous integration, QA as part of a breathing application begins. This is where the Kanban board has an advantage. This, and in the team-oriented approach to work and work product.

Still, Waterfall lingers there in the background. There is that goal. I need to get to the store. I am not sure which roads I will take and I did not know that the shortcut I generally take is closed, but I will get to the store. Waterfall chokes on anomalies – which are more common than uncommon. But regardless, I left the house with a path in mind and adapted. Agile assumes the goal of Waterfall.

Now, who really cares about what these things are called? Who cares about Waterfall vs. Agile vs. Framed Agile or what have you? A lot of people do. A lot of people with vested interest care. They want you to take their certification course and to obviate the utility of their software package for your development shop. There is some merit in this, but not enough to warrant the degree of productization we can see in the world of software methodologies. I try my best to not name names but to ask about a team’s approach. Invariably, words like “sprint” come up – but I take it with a grain of salt and assume it distinct from the hardcore Scrum sprint. You have to be flexible. You have to take all these tools, approaches, philosophies, certifications, and take what is useful and leave behind but keep close by that which is not immediately useful. If you do that, you will be able to adapt and build. You have been doing it since you first drove to the store.

Best,

Josh

I need to do this. I am writing, but this does not belong in the chapter I am working on and I cannot get past it. Therefore, I must purge myself of it. We have been here before, yes. Consider this a duplicate post if you like.

Agile is not Scrum. It is not XP. Okay? Those are commercial terms. A philosophy has become productized and the very tenets of Agile are lost in the nonsensical ceremonious definitions that make up these trademarked and certifiable methodologies.

Keep it simple.

You what to know what Agile is?

Easy.

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

Can we please just build software and get over our cute little processes? Agile only makes common sense. It is the agile methodologies that blow me away with their arrogance. And this post has not been spawned by any project I am working on now. I, as you may know, have a book that is late and I detailing a story about a company I worked with that had their own branded agile process. It had all sorts of checkpoints and mandates and on and on and on. That company crashed and burned.

Meanwhile, my buddy Mike (who I still cannot link to but don’t mind because I get to use him without exposing him wherever possible) built screenr.com off of a totally informal process. THAT is Agile. Rather, that is an EXAMPLE of Agile manifested as agile development.

This is not to say there should not be requirements. With stakeholders come requirements. When you have few stakeholders, it is very possible that requirements can be something you just talk about all day as you build. They change. They are required. That means you NEED to talk about them.

It’s not about thinking outside the box. It is about getting rid of boxes until you require them. Like requirements.

Thanks,

Josh

I wish I have had more time to write. I have been busy with work, but it is almost equally important that I keep this thing current. At least, until the bills come.

I have been working with Kanban and “safe” projects: project that I can estimate without difficulty based on past experience. With Scrum, it is a bit easier to map out sprints and assign estimations to User Stories in order to give an estimate. Every CFO will want an estimate (or a QUOTE, really).

And this is what I want to point out in what amounts to a very poor excuse of a blog update: I am finding that Kanban works great for projects once the development process can begin, but until then, the board is not very useful. This may be obvious, but really, I like to start at the very beginning for every effort and I have found that even my swimlanes are changing based on the Client. This winds up being a symptom of deliverables, as dictated by a contract or project plan. Yes, I still do project plans when I am asked to, which is usually. I stay high level, or as high as I can get away with to avoid making even hints at a promise I cannot keep, but I can bust out a GANTT chart if the situation calls for it and because people like them. In truth, it never hurts to have a big picture view on the wall, however much it changes. It is almost like a snapshot of the initial vision. Well, it is.

Since Agile is a philosophy and not an SDLC or a PLC, kanban fits nicely into an agile SDLC. Scrum extends a bit more into the PLC realm because of the structure and collaboration, scheduling, and metrics that it affords.

Again, I am finding that having a full toolbox is not as important as knowing what tools to use. Estimates will come from experience, and not the kanban board. They will come from whatever formula you have leveraged against the scope of work you are looking at.

Kanban aims to keep things moving and remove restrictions associated with sprints. It seems to do this well, but it also requires, in some cases, a little bee buzzing around and keeping an overall eye on things. Project Managers, there is still a use for you. PMs who only manage budget and resources as though a project is made of lego parts are not getting the full picture. The project is a living, breathing, flowing thing that kanban fits quite nicely with.

It is interesting to me that as “traditionalists” resisted agilie, some “agilists” are resisting kanban. Most of the time, these are not really agilists, but Scrum or XP practitioners. There is a big difference. A very important difference.

When a kanban flow begins, it also creates metrics. Unlike other methodologies, there is *mostly* new information gathered with these metrics. I am reminded of good old PMI when I say that these metrics become inputs into future estimates. Still, kanban does not create estimates and does not demand them. It only allows processes to flow.

A PLC is not an SDLC, and Agility is not Scrum or Kanban or anything in particular. I find it at once interesting and horribly bothersome that as more and more people are focusing on agile methods, two schools are forming; there are those who think Agile deserves and has a place for a maturity model, and there are those who are making things more and more simple, less formal, and just DOING. We start learning how to DO when we are young. Somehow, DOING got us to where we are. We did not predict every twist and turn, and few of us actually executed whatever plan we had in mind when we were in our early teens or even early college years. This is brilliant, and this is the way life works. Why should building software be any different? With Lean development, we learn to not have too much on our plate and only take what we need. With Scrum we learn to work as a team and keep moving forward knowing that we dont know everything. With Kanban we learn to keep it moving and lean on each other, as though the team is a body where sometimes, yeah, you can scratch your leg with your foot if your hands are busy.

I love simplicity. It tends to creep into my mind often that the more complicated something is, the further from a central truth it is. I like truth. I like few integration points. I like the fact that kanban seems to be very good at doing DOING, and that it can be wrapped in whatever presentation layer is required. I think it belongs in every IT PM and IT Team Lead’s toolbox. Right next to the “I don’t know but will find out” and amorphous hat. Top shelf stuff.

I am not a fan of sticky notes, though. This is a problem. They lose their stick too quick. Remember Fruit Stripe gum? Tasted great for about 15 minutes and then you kind of just chewed it. I get about 15 minutes out of a sticky note. Might have a bad batch? This is a fairly new expedition for me, but looking back, I cannot say I have ever had luck with sticky notes. Maybe that it a metaphor unto itself. I am far too sleepy to attempt that dissection at this moment.

Point is, kanban as an SDLC wrapped in a custom PLC seems optimal to me at this moment.

Best,

Josh

BTW, I bought a slew of kanban-related URLs because I was building something that someone built better and quicker than I was building it. If you need one, let me know.