Agile and Military Methods

"What? Dude, your out of your mind! Agile methods emphasize individuals and are cool. Military stuff is all about hierarchy, command and control. Yuck!"

Well, that's one view and I don't really argue about the hierarchy and C&C. But I do find a lot of similarities also. If you need to lead people in battle, the level of trust between you and your team needs to be high. You need to show example and as a leader you go always in first. Would be nice to see the other people following. Your people need to trust you and you need to trust your people. I believe that's a characteristic of efficient Agile teams also. Although in an ideal Agile team everyone is a leader.

And really army and the command and control part is not so black and white. Setting goals instead of giving specific instructions works best in both worlds. In software development requirements change and the only reasonable thing to do is to embrace this change. In his book Management 3.0 Jurgen Appelo summarises agility as

"Staying successful in ever-changing environments." 

In the heat of battle it is probably also safer bet to adapt to the current situation than to follow a predefined plan. US Marines and special forces like Navy SEALs operate with small yet effective teams with no centralized control.

The final example is maybe a bit more far fetched, but maybe just for amusement. If you are familiar with close-order drill, you know that it is a training where certain action is trained repeatedly. After each command the trainer will give feedback about the execution. Now my boldest comparison is between these drills and Sprints/Releases. After Sprint, there is a Review where the results are inspected and the team should get feedback. Improving the actions of the team happens in Retrospective. Iteratively the team improves its execution. Only in this case the whole team acts as the trainer (Scrum Master can catalyze the process).

And finally, practice and discipline are the basic requirements in both. Real professionals keep their heads cool and write those tests before making changes! Regarding discipline, I think the people in software development should take inspiration from the world of military. Lack of discipline in implementation seems to be a common stumbling block for many Agile adoptions. I think the pragmatic programmers and Clean Code movement have understood the significance of practice. Mastery doesn't just appear. It is earned through practice.

In Defence of Target Setting

I have read multiple blog posts about how bad it is to set annual targets and even worse to tie them to monetary rewards. I agree with most of those writings. But still I find myself motivated by targets.

Maybe this depends on how the targets are set. I see a sales budgets as a suboptimal solution (for the company). As a salesman, why on earth would you care how much it costs to develop something you sell? Even if it doesn't exist yet. And you can even give the customer a big fat discount. It's anyway better for you to close the deal than not to.

For sales teams I'd definitely like to have some targets that take into account the overall situation of the company better, the big picture. In addition to the money received from the customer, also the amount of work needed to deliver the product should be taken into account. Preferably the sales bonuses would be counted AFTER the product has been delivered and measured how much the sale really affected the bottom line of the company.

But let me get back to those individual targets that I was excited about. I can openly admit that I have plans for the future. In my role I get to actually affect the operations in my company rather much. I have a vision how I’d like to see things happen. And I spend a lot of effort to make that vision come true.

Then let’s say this vision is well in line with the overall company vision. Both aim to make the company profitable while delivering high quality and desirable products for the customer. In this case I see the target setting as a win-win deal. My internal ambition and the benefit of the company go hand in hand. That's why I have a good feeling that we will both will help each other out.

In short my message is: targets aren’t bad. They are like chainsaw. You can use one to cut trees or for a massacre. Let’s hope the chainsaw is in good hands.

Realism in Software Development

I have earlier written about how hard it seems to be to understand the reality in software development. This time I'd like to share some more examples I have either shamelessly copied from different sources or come up myself.

It is possible to create releases very often without taking them into deployment. Of course this is not something you aim to do, but it is somewhat easy none the less. There can be various reasons, but probably most common is some bottleneck in the process or in the interface between two processes.

If you have a conveyor belt that transports boxes, what will happen if you don't move the boxes away from the other end? They will pile up. Before you know it, if you don't stop the belt, you'll have a mountain of boxes. You probably react in time before this happens. (Also in software development you can utilize for example Kanban to visualize things and to identify the bottlenecks.)

Another example. Let's say you participate in a testing of a new mobile phone model. You get a brand new toy to play with. But then you find out there is a nasty flaw in your product. An irritating bug that destroys your user experience. Naturally you inform the manufacturer. And then they send a person to your home to fix your phone.

Or maybe they will not send anyone to repair it. Probably they will actually just send you another phone. With software products we sometimes don't operate as pragmatically. Instead of just sending a new version, we make a correction to the existing version. This is called patching. Sometimes it just cannot be avoided, but the need should always be carefully assessed.

Keep things visible. Aim to increase transparency. Think carefully about what is really happening and how you could tweak the system to reach a whole new level in efficiency!

Personal Communication and Decision Making

Individuals and interactions. Customer collaboration. I find it really hard to do that without meeting the other person. And if at all possible I prefer meeting them one on one. Or if that is not possible, I usually call using phone or voip. Why? Because it is so much more efficient than writing emails! ..or instant messages or anything else in writing.

I use such tools as JIRA, Lync and Flowdock quite a lot during my days. They are all great for asynchronous communication. And so is this blog post. But getting feedback for anything is a bit too slow to be really agile. Maybe one of the most frustrating features in instant messaging clients is to see that the other person is writing. Then you look at that and wait. If the other person has lot to say, you wait for a long time. But if you go and just have a quick chat it will all be done in no time. Simple and you get to do some nice human interaction also. I count it as a plus!

Well, you cannot always win. Sometimes the face to face conversations may not be pleasant. Sometimes you and the other person just disagree and there might be no getting past it. Or you need to give the other person some feedback that is not so easy to swallow. During those times I suggest just to focus on the facts. Don't get angry or frustrated, just deliver your message. Then you might want to let the other person to cool down before attempting anything mentally challenging. Because frustration simply blocks down our ability to think clearly.

Another interesting topic is the decision making. If I haven't totally misunderstood things, it's actually rather central topic in Agile. Empowering teams gives the teams (and individuals working there) power to make decisions. And thinking about it with some common sense, it does seem wise to do the decisions where the best knowledge is: in the teams. In Scrum the role of the Scrum Master is to remove impediments. A pending decision is an impediment. It's better to make a decision and move on than to waste time in pondering. So, Scrum Master can help facilitate decision making in order to keep team moving.

And I think the same principle applies when going "up in the food chain". Management should provide people with decisions. That's their job. Creating a better working environment through making decisions. Or empowering other people to make those decisions. But that's already a valid decision (and often a very good one.)

Finally I'd like to share this interesting link. Cult of Done. So simple yet so powerful! Starting things is easy. Anyone can do that. But what really counts is getting things Done! Finish starting and start finishing. Have working software as your only metric of progress. Done is the engine of more!

Successful Pre-Planning

Sometimes things just go smoothly! Today was one such day. Today was the Pre-Planning of our next Release. Everyone was well prepared. As I have previously written, we are currently experimenting with Scaled Agile Framework (SAFe). We have Product Visions and Roadmaps. This is an area where we have especially put our efforts on lately and it really starts paying off!

We had a two hour session. First some general information about the schedule and then introduction to not yet so familiar concepts of Themes and Roadmaps. Then the Product Managers introduced their latest Roadmaps and explained the business drivers. It was nice to see the leap in the quality since the previous Release.

After the Roadmaps, the Product Owners shared their teams' draft Release Plans. Some of them were not yet very realistic or contained way too many things, but it was good to have visibility to this none the less. Seeing some draft gives a lot more possibilities for improvement than having nothing at all.

Hopefully this two hour event gave the whole company a better view on where we are and where we want to go next. As the coordinator and facilitator of the event I felt it hit the spot. But I have a tendency of being over-optimistic from time to time. ;)

On a side note, I finished reading Management 3.0 by Jurgen Appelo. Great book! I can already see myself trying this stuff in action.

Understanding the Whole

When a company is in the middle of an organizational change, it is sometimes difficult to understand your/others roles and the expectations. It's easy to stay with the comfortable old routines and do what you have always done. After all, you know what to do, you have done the same thing plenty of times before.

But here's the catch: what if things around you have changed? Things you know how to do might not deliver the value anymore the same way they used to. Or it can even be that the activity you keep on doing is creating a major pain for someone else in the organization.

Unfortunately I can't think of a good example where organs of living organisms were scrambled, but with organizations this can happen. And then it doesn't really work out well if the lungs still think they are fingers and forget to breath. It might have severe consequences even though they are still able to type like they used to. Like in the good old times.

Break the old habits! If you have been assigned to a new role, check what's really expected from you. Are you a muscle cell doing some heavy lifting or should you be concentrated on thinking about the future like the rest of the brain cells? How does your work affect the whole?

Knitting Processes Together

Interfacing is hard. Even if you take a simple example, (well, maybe not really that simple) a software development team and think about how the information flows from the original customer requirement to an implemented feature. Here I'm assuming that there is one Scrum Team developing one product.

First there is an interface between the customer and the Product Owner. The Product Owner interprets the requirements and maybe writes them down as a User Story in the Backlog. Then the Development Team starts working with the requirements and refine them with the Product Owner's assistance. Finally they implement a new piece of functionality. Something that is hopefully close to what the customer originally wanted.

Probably many have experienced cases where everything didn't go according to the customer's plans. Product or service did not meet the expectations. Fortunately this earlier mentioned development process can be improved by collaborating and working closely with the customer. But still, things tend to get a bit harder when you scale.

Depending on how you (or some others) choose to shape your organization, you might have a set of small start-ups where every team can do pretty much everything. But quite often your operations are modelled by separating different functions and processes. And I don't think it's always bad. I'm not really that into accounting, so I prefer someone else doing that for me. Or even thought I like interacting with customers, I'm perfectly fine with someone else closing the deals and me just providing some cool new functionality.

In addition to the different functional roles, there are processes applied in these functions. And these processes interact. In sales function there's the sales process and in R&D the software development process. One of the most common pitfalls in process oriented companies are the interfaces.

Even if you apply the idea of Continuous Improvement, you are usually just optimizing one process. And even if you have a state-of-the-art software development machinery it makes no difference if you cannot get the products to customers. Or if your sales or marketing cannot find your customers and make them aware of your superb new products.

The approach I have recently been involved with is the so called Value Chains. Instead of concentrating only on the individual processes, you take a helicopter view and think about the whole chain of actions from customer need to customer satisfaction. And then examine closely also the interfaces between the processes.

Of course this approach requires a healthy amount of collaboration between the functions. And maybe someone to pay attention to the whole. Quite often we tend to just stay in our little silos and see everyone outside as, well, outsiders. But get past that! Go to lunch with your buddies at sales or go have a cup of coffee with some people working in customer service. Or if you don't know anyone there yet, go and make some new friends!