Practical advice – physical environment

by

I usually write here about leadership and management, but this time I want to share some practical advice. A while ago I started writing a book about the environment agile teams need to flourish.

I write in on a platform called LeanPub – its key differentiation is that you can there publish before your book is finished. I love this approach, appart from all the other benefits (like feedback from readers) it helped me with the biggest obstacle in writing a book – persevering. With LeanPub it is harder to put away extending your work knowing there are readers waiting for updates.

So, so far I managed to cover one rarely discussed aspect of the environment for agile teams – the physical environment. Have a look and let me know what you think.

Did I mention the book is free?

Reconciling “agile” and “traditional”

by

This is a question that I get quite often: how do you reconcile the new agile processes like Scrum or Kanban or new approaches to product development (like Lean Startup) both based on empiricism with old, traditional, prediction based project management methods?

It seems hard because the traditional approach is all about planning & execution as planned whereas the whole “New Wave” is focused on adaptation and shuns planning (some gurus of this movement even called planning a “waste”).

But it also seems hard because agile methods are usually “sold” by contrasting them with the traditional “waterfall” and its failures. As part of their pitch agilists do sometimes even portray project managers as “evil”. To be fair, there is a fair amount of FUD-based pushback from the other side. None of this helps. The two approaches seem mutually exclusive, set to battle each other until the better wins.

But I think that in the real world both quite frequently have to coexist. Here are two ways of looking at this problem that I hope will be helpful.

Tools

It is helpful to try and stop looking at processes, methodologies etc. as being “evil” or “good”, “stupid” or “smart”.

Each and every one of them evolved in a certain environment and context with best of intentions. Probably each did work for some problems and some people – otherwise no one would try to reapply it. That – say – the classic waterfall is an utter failure in software development doesn’t tell us it is a stupid approach. It just tells us it doesn’t work well in one industry, with a particular type of work. It still may work pretty well somewhere else, it works pretty well in civil engineering for example.

What is important here is that once we realize this and stop looking at methods emotionally we may discover that they are just a set of tools. Tools that may be useful no matter which “camp” they come from. This is how a pragmatic manager should view them.

An example I like to make is the Gantt Chart. It is seen by many ‘agilists’ as something akin to the ‘mark of the beast’, a sign of the “evil” project manager. But if you take all that emotional baggage away it is just a tool to visualize dependencies over time – and this may be useful should we need to do just that.

Perspective

One of the basic principles of agile is that software development is way too complex an activity to be perfectly predictable. This is the primary reason for predictive methods’ failure. Too many parameters make predicting exactly the amount of work necessary to build a software system close to impossible. And then the requirements almost always change once work is already underway.

However, the key word here is “perfectly”. If we look at a software development or implementation project from a different perspective it may turn out to be predictable enough to be a part of an overall project plan.

Let us suppose for example that you want to open a bank. First you would probably want to asses whether you have enough funds to do it and whether it is a good idea. In order to do that you must have some basis to calculate the costs and estimate the profits. You would probably also want to estimate how long it will take to get your bank up & running and then how long before you will get to the break even point.

From the budgetary perspective you will need to put aside a couple of millions for setting up branches (rent, decoration, staff), another couple for marketing & advertising and so on.

You will also need a computer system to run your bank. You will obviously contact a couple of vendors and maybe a bespoke software development company. You may even consider creating an in-house team and building it on your own. No matter which option you will choose on this level of planning it is quite predictable. Let us say you can safely assume implementing a system like this will cost – for example – 750 kEuros and will last between 10 to 12 months.

For the purpose of creating a rough budgetary plan for a bank this information is sufficient. At the same time it doesn’t really matter on this level what detailed features the system will have or how long the work would take in terms of days let alone hours. It wouldn’t change the overall business plan / picture anyway.

Where it gets unreasonable it is of course when someone expects to have all the features from the 300 page spec document on October 11th for the exact price of 747.881,35 Eur. So, software development is predictable – it is just not predictable in a way that is regrettably the basis of most contracts for this type of work. But this is another story.

Summary

There are no “good” or “wrong” tools – there is inappropriate use of tools to things they were not designed nor intended for. Projects can be predictable even in software, but only on a general level and only to a certain degree of certainty. Plans are just plans – how things will really go no one knows.

Once you keep all of that in mind you can use any tools whenever you think they fit the purpose without worrying whether it is “truly agile” or “proper management” etc.

The Dark Side

by

If you take any book on leadership and management or go to a conference you will hear a lot about team engagement, servant leadership, inspiring people with a vision, fostering their internal motivation as craftsmen and so on. This is what I’m advocating here as well. All of that – and more – is part of the New Wave of Management, and it is not only ethical, but also firmly based in experience and science. In other words: those methods are not only good – they work.

There is, though, a completely different approach to leadership and management out there in the world. It is based on exploiting people’s weaknesses rather than strengths, on controlling rather than trust, on fear rather than joy. That is the “Dark Side” of leadership.

And let’s admit it openly: it works too. You can build a pretty large business by bullying people, by exploiting their lack of self esteem and fear of unemployment, by preventing them from growing as persons and professionals throwing them away and replacing with new “resources” as needed.

I have seen o couple of companies built using the power of the Dark Side myself and I bet anyone who has more experience in the industry had too. They are usually centered on the money. Their only real goal is profit. There is no mission or vision beyond that – at best the founders/owners are doing it also for the pure fun of running a company and being in power.

Some may say that such approach can only bring a company to a certain point. And they would be right – the Dark Side companies are unable to create innovative, “insanely great” products or services. But that doesn’t mean that they can’t grow, make their owners rich and be around for a long time supplying mediocre products&services. True, the best talent will not stay there, but many unfortunate souls will spend their work lives in such environments.

The Dark Side is not taught in MBA classes, there are no blogs about it nor conferences where its gurus would share practices. But somehow it manages to be there in so many places – it doesn’t take a long search to find its practitioners. In my observation it is usually people who worked their whole life in such environments who gradually become like their bosses, and once they assume a position of power themselves they perpetuate the cycle.

They can sometimes hide behind nice slogans and even agile methods, but once you feel distrust and fear in the company culture you will know the Dark Side is there.

Why I’m writing this? Because I think we, the practitioners and evangelists of the New Wave of Management – or the Light Side if you will – should be open about one thing: the choice of leadership methods and ‘tricks’ is not purely pragmatic, based on their effectiveness. It is also an ethical choice, rooted in our beliefs and morals.

May the Force be with you!

Requirements for software – a dysfunction?

by

Traditionally software development is driven by requirements – descriptions of functions the product should perform once done.

In the past those requirements were handed down to the development teams as a bulky specification document. Now, with agile methods being widely used they are usually put on a backlog. This backlog is managed by someone – sometimes called a Product Owner – who can move requirements up and down at any time etc. We all know this. This change alone did bring a lot of improvement. It enabled flexibility in responding to change on the product level and helped reduce waste from implementing unnecessary features.

The problem is I think this is not good enough. I think the problem is the requirements themselves. I think we could even call them dysfunctional.

Here is why.

Requirements – as they are practiced by most teams now – are deeply rooted in the sequential, cascading way of building products, with its clearly divided silos of narrow specialists. In each silo those specialists perform on the product the single activity that is their specialty, then pass it on to another silo. Understanding of the product’s purpose, understanding it as a whole is unnecessary – or at least not crucial and expected. Everyone is supposed to do well the one thing that is within their competence – and such are obviously also the limits of responsibility and expectations.

If a piece of software is needed to solve a business problem a group of “business specialists” creates and describes the needs (sometimes already selling the result to clients), then passes this description on the silo with “analysts” who in turn produce requirements, that are in turn passed to the silo with “programmers” as a description of what they are supposed to build – and so on.

The key dysfunction of this model is not even the specialization of workers (an idea stemming from 19th century industrial revolution and its 20th century success – good for making repeatable physical products in mass quantities, not for creative intellectual work), that fails to engage their full potential. The key problem here is the alienation of workers from both the product and other silos. The result is lack of shared responsibility for the end product, especially for it being indeed a solution to the original problem.

This is why a typical employee feels he has no influence on the product nor the company as a whole. This feeling – so common in larger organizations – is killing engagement and creativity. Instead, it fosters an attitude typical of the “deferred life plan”: I sit at work doing something I don’t care about only to get paid.

Agile changed a lot within the development silo. In most companies we no longer have “internal silos” – analysts, programmers and testers working in separate departments (companies that still don’t get it will change or die out). Teams share responsibility for the product, but they share that responsibility only on the technical level, not on the product level. So yes, it helped, there is more engagement etc. but the alienation between business and development continues. Common attitude in the ‘development silo’ is now “we are blacksmith trolls down here, we forge whatever is asked of us, we do it well because we pride our craft – but whether that makes sense, solves client problems etc.? We don’t care. It’s the problem of the business trolls”.

I think part of the problem here is requirements in their traditional form. What does it change if we put requirements handed down the ‘development silo’ from ‘business silo’ on a “product backlog” and call someone “The Product Owner”? Very little. This still doesn’t full potential, brainpower of people in the organization. It still the old waterfall, just one level up. In fact, once we have backlog etc. in place it may make the problem less visible, because now that “we are agile” everything seems ok.

I think that what agile is all about – at least as much as I understand it – is creating teams that will collaborate to deliver products having shared responsibility for them – and influence over them.

To achieve that we need to break one more silo – the ‘business silo’. We should build true crossfunctionality by including the “business specialists” on the teams. And teams should get problems to solve or ideas to validate, not requirements.

It seems like a small change but it is, in my opinion, fundamental. Implementing it means shifting everyone’s thinking. Implementation is no longer a goal in itself for the team – solving the original problem is. Everyone is involved, everyone’s ideas count not only regarding the technical solution but the overall solution. And responsibility is shared too – no more finger pointing blaming the other silo – “stupid busines” or “lazy developers”.

Can a backlog and a role akin to Scrum’s Product Owner still help if we have problems/ideas instead of requirements? Yes. Keeping a list and deciding which ones to address first is helpful. Backlog makes the problems/ideas waiting to be addressed visible, helps gather more information about them, serves as a communication device for other teams. A role of PO can help if it is hard to decide on the order on the backlog – if consensus can’t be reached someone has to step in and decide.

Conclusion is: want true agility? Get rid of requirements! Instead create really crossfunctional teams that include non-technical talent you have and have them work a backlog of ideas/problems.

Note: I’m fully aware what I call for is already how things are done in best, most innovative companies. I’m also aware this is what at least some of “agile gurus” had in mind when they created the backlogs. Yet still I frequently see companies who claim to be agile yet persist in keeping development and business silos separated. And they stick to requirements. I truly believe changing from requirements to ideas/problems could help transition further.

Why corporations don’t innovate

by

Over and over again I see this question raised and discussed. Different reasons are proposed, but I think the main one is the corporate culture.

Innovation is, by definition, trying a new way of doing things that has not yet been tried before. This is inherently risky as failure is the most likely outcome. As I wrote in another article an environment that supports innovation must, therefore, be one that at least tolerates failure if not embraces it as an inherent part of the learning cycle.

This is how the world of startups operates, as most of them fail. Startups are created and initially managed by people who act like gamblers, trying and trying to hit the jackpot. The only difference is that they learn from each failure and try a new way to play the game every time. The “startup game” is a game of taking risks with innovation in search of success.

By contrast, the game played by employees in a typical large corporation is responsibility avoidance to maintain stability.

Since the cultural goal of a corporation (and the only thing it truly excels at) is prolonging its own existence, so the goal of each corporate employee is to keep his own position in that corporation – or at least within the corporate world. This is achieved primarily not by being associated with successes, but by not being associated with failures. That is why any form of excuse or cover that would allow a person to prove they were not responsible if a failure occurs is so sought after. The cover is, of course, stronger if it is formal and proves all precautions against failure were taken – a fixed contract, a risk management plan, an approved business plan etc. Also, that is why decision making by committees (responsibility dilution) or escalating unnecessarily decisions to executive level are so common in corporate culture.

Taking risk inherent to innovation is completely against the values of such a culture.

The question many ponder is how to create a corporation that would be open to risks, would embrace failure as part of the learning process – yet be large, rich and winning. I don’t think it is possible except in some rare cases. This is so, because the corporate culture is not a product of an evil conspiracy but rather of objective conditions such an organization operates in. It is above all expected by shareholders – and employees – to be predictable, stable. The best way to being predictable is by being efficient in doing what it already does – by – in short – avoiding risks.

However I think a better question is: would it be really good even if it was possible to create un-corporate corporations? Most people want stability and predictability both in their investments and in their work. And we all need mass produced functioning goods and standard services that are – let’s admit it – best provided by the corporations. Corporations don’t innovate – because this is not what they are built for.

From that prospective the fact that small & nimble startups innovate only to be later taken over by corporations or grow into ones is perfectly healthy. After all, if there were no “big boys” to buy out the founders many of them would loose their “exit strategy”.

Culture is everything, processes are nothing

by

A change is underway in management, especially in high-tech companies. This – as I call it – “New Wave of Management” started by the Agile and Lean movements now includes other ideas like “Management 3.0” or “Radical Management” (both also excellent books). It is visible also outside software development with companies changing their structure to small, self-organizing teams inside a decentralized, cloud-like organization.

Despite all the great changes – more humane workplace, more meaningful work, higher effectiveness – this New Wave is bringing I feel there is still too much concentration on processes and structures among its disciples. This is probably so because many of the influential thinkers and writers are so fascinated by them – which is hardly surprising, given this is what they analyze, write and talk about.

However, many times I have seen all those great processes, methods and structures fail despite being “implemented” to the letter. The reason was always that the given organization’s culture was not compatible with them and rejected them just like body’s immune system rejects alien cells. Agile – and all New Wave approaches and methods – work only in a culture of openness and trust, in organizations that have a clear, engaging vision and a mission that is relevant and true.

“Culture eats strategy for breakfast” is a well known saying, but it seems culture eats much more than this. I always say that “Culture is everything, processes are nothing”.

Anyone attempting an “agile transformation” should first take a hard look at the current culture. But given the fact that most (70%)projects to change organization’s culture fail this is an important message for those starting a new company: startups.

I wonder how many startup founders even think about what type of company they want to create? I’m afraid many are too concentrated on their product/service idea, on getting funding, on getting going…

“People buy why you do it, not how you do it.” says Simon Sinek – and he is right. Just remember those “people” is first your own staff, your first team. If they don’t share your core why, if you can’t sell it to them then how are they going to build products or deliver services that will thrill your clients?

If you are a startup founder please stop now and consider this: besides the product/service you’re so focused on you are also creating a new organization that may potentially outlive your involvement (or even yourself). The culture you will give it, instill in it now, at the start will decide not only your chances of success. It will also shape its future, probably many years after the product you are so concentrated on will long be obsoleted and gone.

Managers’ common errors: trying to be everything

by

I have recently met with a team whose manager was trying to be their Product Owner, their Scrum Master (the SM originally assigned to their group kind of slipped out unnoticed a couple of months earlier), their technical leader – and at the same time think of their department future, lobby for the product they were making (an internal system and associated framework) and overall provide political cover. One of our trainers was leading a retrospective and as I was listening in the team told that manager a couple of times: let us decide, let us do things, let us fail even. What was amazing was how those statements bounced off him – it was like if they were speaking Mandarin, the guy just didn’t notice.
This is a pattern that I see often: a manager that is trying to be everything for “his” team, play all the roles at least a little bit – and in the end fails to do any of them well. I think drivers of this behavior can be different in each case (for example this guy is not a power freak, but rather is intellectually drawn to everything: to him all is interesting and worth exploring, knowing, so he tries to get at least a bite of everything), but the net result is always the same – employees’ creativity is stifled, after a couple of tries their own initiative is gone and healthy self organization has no chance of occurring.

This is, of course, nothing new: delegation was always a challenge faced by leaders. However, the “traditional” delegation was the delegation of tasks – what we call for now is delegation of power, delegation of problems to solve. Even more challenging – so even more managers fail to do it right.

Key takeaway: if you are a leader don’t try to be everything, focus on what value you can provide (most likely strategic decisions or providing a compelling vision or coaching) and don’t get in the way of the team.

Want innovation? Embrace failure!

by

A theme that I see repeatedly in companies I work with is that they boast how innovative they are. Usually that means their managers demand from their staff to be innovative. At the same time, however, they remind everyone that deadlines have to be met and all has to delivered – and it has to be done! In other words, they make it very clear that there is no room for mistakes and everything has to be done as planned (or, more frequently, as it was already promised to clients by sales). Then they wonder why they get little real innovation – the most obvious answer being that their employees are stupid, because Google scooped “all the good ones” from the market and so we, poor managers, have to do with these lazy retards. How wrong!
Innovation is, by definition, trying new ways of doing things that have not been tried before. If you look at it from this angle it is obvious that more often than not this must end up in a failure. Most things no one tried before are not good ideas – only a few are, but you won’t know it until you try them. And even if you stumble on a really good idea it will need a lot of perfecting and improving before it will be a useful product. “The devil is in the details” – so this process will also involve a lot of failures.

Therefore, in order to have innovation you must make ample room for failure. That means you have to make it safe for people working for you to try new things. They have to know that if they try something new and it won’t work they will praised for trying rather than punished for failing. That is what “investment in innovation” really means. It is not about creating an “innovation department” or buying new hardware or “managing innovation”, it is about being ready to pay for things that very likely will get thrown away.

Someone may ask: what if we can’t afford it? What if we don’t have money to spend on things that won’t work? Then you can always be at least honest with your people (which is always a good idea anyway) and tell them: don’t try new ways of doing things, lets stick to what we know will work, because we have very little room for maneuver this year/quarter/whatever. They will understand. And you will not fool yourself you are “innovating” when you can’t.

But does it really take that much investment in terms of cash to foster innovation? I don’t think so, but this is a topic for a separate post.

Want change? Have courage!

by

The most common complaint I hear from developers is that their managers push unrealistic deadlines on them. The managers come and say something must by done by this date – and won’t take “no” for an answer. The developers then work nights to deliver on a promise they didn’t make – usually only to get more features added two weeks before the deadline.
This is a fair complaint, the only problem I have with it is that the developers generally deliver. The managers in the end do get what they asked for – at least it looks so on the surface. No wonder they come again and do the same thing. Their whole experience tells them this is how things work and many of them genuinely believe they act correctly by pushing unrealistic deadlines on their subordinates (known under a number of euphemisms like “challenging workers” or “driving folks hard”). How are they supposed to know this is achieved by degrading quality of the end product? Usually they lack knowledge and time to thoroughly check the product and many ill effects of poor craftsmanship in software take months if not years to become painfully visible (technical debt).

In other words developers just train their managers in dysfunctional behaviors, over and over again confirming their experience that those behaviors will produce desired outcomes.

So, if you are a developer: yes, your boss is probably a moron and yes, he demands stupid things – but it is also you who trained him that way by delivering those things. No wonder he comes for more. It is a vicious cycle. Want to break out of it? You have three options available to you:

  • keep on doing the same thing – write poor code, quick hacks upon hacks, with no tests under pressure just to keep unrealistic deadlines and occasionally complain out of your boss’ earshot to other developers or a passing trainer/coach/consultant hoping in wain things will change on their own,
  • change jobs in hope of ending up in a better environment
  • or try to change the current environment by saying “NO!”.

The only problem is that if you refuse to do stupid things you risk your job. And this is where courage comes into the picture. The rule is: if you want to change anything in your workplace you must be ready and willing to get fired over it. Otherwise you will give in, you will buckle – and things will stay as they were.

Improvement is boring

by

The empiricism underpinning all agile methods means that people live in a constant inspect & adapt loop. It is primarily about the product being worked on – but it also applies to teams themselves. The idea is that with agile not only the product evolves and gets better, but also the teams – and thus people teams are made of. This is one of the claims as to why agile is inherently better than waterfall – it not only produces better products, but also better teams. Some agile methods recognize improvement in teams’ ability as an important part of the process and prescribe tools to foster it – for example a retrospective producing actionable improvements every sprint is a required part of Scrum.
This is all very nice & good, but the problem is that improvement is a slow, monotonous process. It is rarely achieved by doing something spectacular. It usually means adjusting work methods, coding styles, design habits and daily routines. Often those are small adjustments or they are achieved by a series of small steps through time. It means taking the actionable improvements seriously and honestly striving to implement them every day, every iteration (sprint to use the Scrum term).

Why is this a problem? Because there is little joy in this as the change happening every day or every week is so small it is imperceptible for those involved.

How can we solve it? By making the improvement visible – and by keeping the work itself fun and engaging.

One great tool is retrospectives – they should not be solely about hunting down problems, but also recognizing, even celebrating improvements that the team achieved. There is a strong tendency to be negative during retrospectives, to concentrate on what didn’t go well as opposed to recognizing what was right. A more balanced retrospective gives team a chance to realize how much they have improved since the last time.

Another idea for making improvement visible is encouraging both internal and external sharing of knowledge and work through talks and conferences. If you talk to peers about a craft you share you will frequently find that what is already part of daily work for you is a discovery for others. This is the moment when you realize how much you have improved. Organizing a monthly, internal “tech talk” or encouraging people to submit talks to conferences is a way to foster this.

In any case I think it is the Scrum Masters (or Agile Whatevers) role & responsibility to make improvement visible, at least from time to time. It also part of the responsibility of managers overseeing the overall development organization. And it all starts with recognizing that improvement is boring…

Update:
This problem is not exceptional to software development. It is exactly the same in other crafts/skills – path to mastery leads through small improvements.

In fact, it should be easier for software developers, because in their case the improving quite frequently means learning something new – and this rewarding in itself. Others have it harder, because in other activities improvement comes through repeating same things over and over again. Musicians play & play same tunes for hours to get better. Soccer players repeat same standard moves as part of their training.

What is common, however, is that a) it takes discipline and willpower to improve and b) from time to time the improvement made is made visible (a musician plays a concert, a soccer players plays a match).