Work in software development is made up of 2 essential parts: planning and doing. It stands true for any methodology, be it agile or lean or any other variety thereof. The theory of project management has it, that a project can accommodate 10-20% of time spent on planning, tracking, adjusting trajectory, wiping the binoculars, etc. At least, we used this approximation when I worked in an outsourcing company many years ago, and it varied depending on the challenges the project was facing.
With projects, this world has only 2 options for anything else than doing:
Option #1: the bulky “talk-plan-remake-do it again” cycle is a given.
Option #2: over-indulgence in all things talking and planning is a waste.
The hardest job is to distinguish if a project falls into option #1 or option #2. If the option #2 is disguised in the make-up of a given, developers and other performers will feel troubled about whatever they’re working on. When someone has a job to do, all they need is to be left tete-a-tete with their work, and as little contacts with the outer world as possible. If a stretch of work — be it during the day, or over longer periods of time — is interrupted by previously overlooked hurdles, the drive to ship is replaced with something like this.
The unwelcome “talk-plan-remake-do it again cycle” usually happens if planners are not directly involved in the ship-deliver activities, and lack foresight in tracing the hurdles in advance. For the actual performers, being subjected to all kinds of catch-up moves feels like a huge annoyance. Performing is a raw and healthy thing. Some software developers naturally feel more inclined to performance-based activities, and their philosophy is: “I care only for what I have to ship, and I don’t want to mess with the waste of talking.” If we draw a parallel with performance on stage, the feeling after having shipped a piece of work would be akin to this: I’ve worked my a.. out, I’m sweating and exhausted, but I’m happy because I performed and delivered the show that people liked!
There’s nothing as fulfilling as a happy experience of a well-accomplished performance, and performers find delight as they ship something on any given day. All the tiny dwarfs in the world run a round of applause at that. The deliverable can be a piece of code, or those few milliseconds of faster load times, or a finished design element, or an HTML-coded web-page. If it feels like too much unwanted planning and discussing that undermines this desire to perform, your team is in trouble. This feel signals that the whole act of planning is misinterpreted, and is seen as a thing-in-itself that lives in isolated reality, unrelated to a shippable outcome. Besides, it’s a proof that the keepers of “talk-plan-remake-do it again” routines lack competence in nailing down the optimal solutions at the right time. If that’s what’s happening in your organization, remember that talkers and planners are not the rainmakers. Performer is the rainmaker, and planners would be better off if they let performers perform, or better yet, get to performing and doing rather than talking and planning. The catch here is that with time some sort of organizational blindness might develop, as talkers and planners manage to come across as rainmakers. Beware that optical illusion.
… and why it implies a lot more than what we see on the surface.
I guess it wouldn’t be an exaggeration to say that software development is the most knowledge-intensive field of production there is. No other industry is relying so much on the balanced influences of society and technology. The ever-changing ecosystem of software development thrives on knowledge… or is it wisdom… or is it information… or Big Data? There might be some confusion here, because “Big Data” is a lot more trendy term these days than “knowledge” or “information”, not to mention “wisdom”. With so much emphasis on data, the other three options look greyed out. Little is being said on why organizations might or might not need it, and where this whole movement is rooted. Curiosity may have killed the cat, but it can for sure save many humans (and bucks, too), so I took a deeper look into all things Big Data and came to some interesting conclusions. It makes sense to note the points of departure and destination before carelessly catching this train.
Previously I’ve been exploring how human needs and reactions triggered the rise of agile and then Kanban. The Big Data trend is tied to human-related incentives as well. To the shortage of some skills required to fulfill some needs, to be exact. Let’s look into what those needs and skills are. Fast backward to the early 80′s, or even 70′s. Not to go into too much detail, the trends that started prevailing in education around that time were shaped by the philosophy of pragmatism — and still are. I’m talking about the United States mostly. The summary of this philosophy is: business only. When young people make their educational choices based on this thinking, they want to pick a profession that would give them the fastest pay off on the college loans. Computer science and finance seem to be best suited for that. This narrow specialization looks like a reasonable way to get to earning money fast. This “business only” trend in education delusively looked (and still looks) like an excellent option. Why would someone need more skills and more knowledge than exactly required for doing their job with computers or with finances? That’s where the trap is. With several generations of engineers and tech business executives who majored in their narrow specializations, the community of tech professionals encased themselves in one-sided thinking and experience. As these people find themselves living in their tech-only universe, and at one point feel the lack of skills required for wise decision-making and business leadership, they only have their limited domain to look for any clues and hence resort to the Big Data or artificial intelligence panacea. Obviously, IT businesses are in permanent shortage of efficient leaders who can steer the wheel sensitively and wisely. The current setup of mass education, however, be it high school, college, or university, is not suited for raising such individuals. The point is that a proficient tech leader has to be knowledgeable in humanities, in addition to computer science. Someone with technical background will probably want some scientific proofs for that argument. I have those proofs, and I hope to share them in an article one day, although it might be quite hard to prove that technically. Technical background endows people with the ability to keep mental focus, no doubt. But the ability to focus alone is not enough. What if the focus is on wrong target? From what I’ve observed, techies mostly fail in seeing how nuances and small things can make a big impact. Tech business leaders have to wear many hats, see the big picture, stick to common sense and mix it with foresight and intuition. That’s what humanities bring on the table. People of such mixed breed have become a scarce treasure these days.
Back to Big Data. This trend is there for a reason. Technical folks genuinely want to squeeze all they can out of their limited technical universe. That’s about the same as with Newtonian physics vs. quantum physics. It’s neither good, nor bad, just too narrow, and techies are taking the course of action they believe to be the best. There are exceptions, of course, but exceptions only confirm the rule. This guy has delivered a presentation called The Ephemeral Role of Data in Decision-Making. I’m sure he has some sort of humanities background behind, if not through the formal schooling then in some other way. Big Data is touted with many trumpets, and it would be a professional suicide in some organizations to stand up and question the common sense side of this “golden” rush. Techies eagerly measure all they can, assuming that the count of molecules in water will dictate the shape of ocean waves, figuratively speaking. By the way, the original concept of Big Data stood rather far from where it is now. It was about physical space needed to store all the data in the 80′s – early 90′s. With the storage costs declining, the Big Data trend found an outlet in another barn and took its current shape. The overvalued significance of Big Data reminds me of the days when they sang lavish praises to Facebook, until with time it became clear that it is harmful for people’s health.
Summing up, the Big Data trend and its misuse is rooted in the short-sighted approach to education. We are facing the consequences. Too few technical leaders can rely on their own guts and broad background in making smart business choices. As if enchanted, they see nothing except the very questionable maxim that past trends will predict the future trends and hence provide some safe ground for their decisions. Hell, no. But someone will reap the produce as there’s a whole tribe of consultants and companies waving the banner that reads “leverage your BigData”.
As you read the article, you’ve probably noticed that my conclusions come from various sources: trends in education, philosophy, social sciences. Thinking is the hardest job. Joining the flock is much easier. A mule tempted by a carrot will sheepishly follow the carrot anywhere without thinking. It takes more than being a mule to stop, look around, contemplate the hidden driving forces of things happening around, and take a sober unretarded decision as to what your organization needs. Big Data has to be approached with reason and caution. There’s no point to collect data just for the sake of measuring. There are many other more interesting things in the world to do, rather than that. Speaking of interesting things, humanities combined with computer science education — that’s what we need to grow smart tech leaders. Yes, there are costs involved. But where will the cost be higher, and for whom: letting it all go with the same impaired narrow education, or finding a way to nurture thinking individuals who are indispensable in any positions of governance, not only in IT?
Prioritization and Big Data? Think Human Nature
A couple months ago I started a series of posts about communication (see Non-Violent Communication for Agile Teams). The concept of non-violent communication has been introduced and championed by Marshall Rosenberg in his notable book. As I received feedback from readers on that post, some reactions could be summarized as follows: “What are you talking about? Which violence? Do you think we behave outright violently when we communicate at work?” I pondered that, and came up with a bit re-framed concept. While Marshall Rosenberg has been dealing with people from various spheres of life, e.g. jail confines, family violence, and other cases of the outright aggressive behavior, we have quite a different situation as IT professionals. We can not be violent per se; this is office, work and yelling at someone, or using physical force (which would be perceived as the ultimate violence) is out of question, of course.
So, I’d like to give a bit different highlight to the subject of communication in agile teams, calling it “non-judgmental communication“. If we think about it, in its verbal form, in a well-behaved social environment, what would the utter form of this “violence” be? To me, this is accusation. For example, when a person in a team publicly blames another person for a failed release, saying: “It’s all your fault. You’ve missed this thing in the code. You overlooked this bug. You’re the one to blame for this late release”. It’s an utterly simplistic example, just for the sake of example. From what I see, the culture in most software development teams does not allow people to be that bluntly accusing. We are all human, and we know that people must have their reasons for the delays, or problems with code, etc.
The next gradation of violence in agile teams would be judgment. Someone might ask, why on Earth can judgement be a form of violence? Let’s look deeper into that. The most common example is calling a thing someone else has done “good” or “bad”. Especially when this judgement comes from someone in a position of a formal or informal authority. Like, your code is “good”, your design is “bad”, your article is “good”. Think about it, which value such an evaluative adjective would bring to what the team is trying to do? It’s only a judgement, and it suggests no way out. Doomed. However, what we are looking for when we work in a team? We look for the ways to improve. To keep our colleagues encouraged to perform at their top ability. To me, the “good-bad” judgment ultimately kills this spirit of friendly feedback and improvement. Okay, you say that this design is bad. But have you noted that this person is truly searching for a sweet spot? That this person genuinely cares? That he or she wants to come up with the workable solution? Why not reach out and help? Same with the written pieces and presentations. The best thing one can do is express their perception as a feedback. So, instead of saying “this presentation was the best”, we need to learn to say “this presentation was of most interest to me. I find it well prepared”. If we want a more fitting word instead of ”good” to express our attitude, I have this friendly word ready: interesting.
Now, someone might ask why it might sound so upsetting to the other people when someone else gets the “this one is the best” score. First of all, everyone invests their best effort in what they do. The judgment given to only one out of many might sound especially painful to those others, if they feel underappreciated for their input. They would then project their feeling of being underappreciated to this “good” praise that goes to another bird in the common flock. Someone might call this nonsense, but it’s as serious as it can get. It’s all in the culture. If the feeling of underappreciation is mixed with the judgmental “good” that goes to another peer, this is a flammable mixture. It’s a far graver cultural flaw than one might see on the surface.
This whole subject of judgments can acquire another perspective. Some of you might have heard of the Dunning-Krueger effect. In short, this is when the incompetent rate their skills high simply for their inability to recognize their mistakes, and the competent are too harsh on themselves. For agile teams, this might have a consequence that competent professionals who suffer from this bias, might get all unenthusiastic about their abilities at all, which in the end would mean losing out for the whole team, as they won’t be able to capitalize on the skills of the competent ones. On the other hand, we tend to be very condescending to those “incompetent”. If someone does an utterly improper thing, and then goes how great he is, we somehow rather laugh at this person, whereas a harsh judgement could be a proper response in this particular case. It’s a very fine line, and certain psychological skills are required to keep it. Remember the Emperor’s New Clothes tale? No one dared to say that the emperor just had no clothes on, until a young boy voiced the truth. Actually, there’s another human reason for this loose attitude. Subconsciously, we might feel that we are superior to the incompetent ones, that’s why we “let them live”, just to make fun out of them, keeping their heightened false beliefs of their abilities. In such cases, a shock treatment might be needed, and something like a judgement really needs to be expressed. Like, dude, can’t you see that what you say is absolutely clueless? This will be like a sobering shower for this incompetent person, and finally it would help them form a realistic understanding of their abilities, and improve, if not in the area where they’re clueless, then in something else.
The benefits of non-judgmental communication are enormous. Organizational culture does not emerge overnight. This is something that builds up with time. The first steps that one might want to take looking to introduce the non-judgmental culture, could be this: watch yourself, whether you use judgement when giving feedback about someone’s performance. Note if you’re inclined to “good” or “bad”, and consciously replace it with “interesting”, or “smart thinking behind this code”, or “I can see that you’ve put much effort in this design”. If you need this person to improve their work — this means, to make the design more compliant with the objectives, etc. — rather give them some advice. Creative people are usually very sensitive. They need to be treated like fragile antique vases. *almost no kidding*. To get the best of their abilities, one has to learn to communicate with such people. Acknowledge their input. These are all very subtle things. But devil is in the details, and software development is more about people than anything else, and I humbly hope that my posts contribute to this shared awareness.
Non-Violent Communication for Agile Teams
Are You Dumb?
The Dangers of Small Talk
How Communication Factors In To Production
I’ve been contemplating recently about agile movement as something that has risen from software developers who felt that the challenges of their work are not addressed by the waterfall approaches of the industrial production, and shared my thoughts in the Back to the Future of Agile Development essay. Then, as another layer of this thinking paradigm, I saw that Kanban as a method in agile software development stems from the human need to get rid of deadlines (check out the article Kanban as Multiban?) Now, there’s another concept in project management that falls into the same pattern. I’m talking of what is known as “project portfolio management” in the enterprise lingo, and what we call “multi-project prioritization” for smaller agile companies. So, this time I want to look deeper into prioritization, and give one more example of how a promising new trend stems nowhere else as from human nature.
On to project portfolio management. Just as waterfall was copy-pasted from industrial production, and turned into the Rational Unified Process for the sake of software development, in the same fashion, project portfolio management has its roots in the financial investment industry. As always, there’s a human need behind it. Someone must have been tired of looking for the ways to manage risks in software development projects, and resorted to what seemed the closest available counterpart — financial investment. But if we look deeper, would there be any difference between financial investment and following through many projects to completion in an organization? For sure, yes. First of all, projects are not shares or stocks, and in investment management one is looking to lower the risks, and compile the investment portfolio in such a way, so as to mitigate them, and optimize the financial gain. Only that and nothing else. It’s not that this person is concerned with being strategically involved with a public company whose stocks or shares they’re buying.
It’s far more complicated when we deal with projects, and especially with software development projects. One key difference is that the projects are meant to be followed through to completion. Of course, a lot depends on the organization. I figure that IT and software development projects could be shuffled as investment stocks — the closest match — in budgeted research fields, like in the military or in the government projects. Most IT companies, though, have nothing to do with picking up or giving up on projects. While in the finance industry the only value indicator is financial gain, there are many more value indicators in software development. Usually, the question is not if the project should be picked up or given up. The questions are:
1. Are we fitting in the budget? Do we need to secure a leeway to complete our projects?
2. Are we lax in terms of time? Do we need to sacrifice some parts of the project, and skip them, in order to ship some workable software in time?
3. How about people? Are they all balanced well in the projects? Have we made sure that the team’s collective energy is sent in the right direction?
4. This one is the closest to where we might come at portfolio management. Let’s say you work in a large organization and you have many projects, as an IT director, to supervise and to report on their health to someone standing higher. Or, in a smaller product dev company, one might have this multitude not with the projects per se, but with what we call “product features”. Ironically, for a smaller organization, this would seem the closest approximation to portfolio management. We have to prioritize and decide, whether we skip this feature, or follow through.
On all of those 4 levels, it’s about prioritization. That’s what it’s all about. Prioritization is the toughest job of all in the world, be it in personal life, or at work. Sacrificing is the most daunting challenge, and it imposes a huge load on a person or a group of people who are supposed to decide and prioritize. By now, the buzz in the industry says that the concept of “project portfolio management” has something missing in it. The tools for multi-project prioritization are not universal, and they don’t do the magic instead of this tired human being. Either the tools have to be customized (at big costs), or they miss some instrument that is crucial for this particular organization. In a nutshell, the project portfolio management concept has outlived itself for effective prioritization, just as RUP had outlived itself previously, and was replaced by agile as a methodology in software development. But still, as a product owner, or a project manager you need to have a birds-eye view on all the risks. Still, you want to get this burden off of your shoulders, and finally get a tool do the bulk of the prioritization for you, as this is the hardest job in the world. What happens usually when some methodology is not working out as expected for those human beings? Right. They’re on the lookout for new, better — and what’s most important — easier ways to prioritize.
Voila: enter Big Data. There’s much talk going on about it now. This is the next big thing coming, as it is supposed to make a productivity breakthrough in prioritization and decision-making. If we draw a parallel with the previous occurrences of groundbreaking phenomena (like, the way agile appeared in software development, or how people resorted to Kanban within the agile paradigm, or how they looked to use investment portfolio methods for project management), this prioritization seems to be the hardest job that IT professionals want to make easier for themselves, intrinsically.
Big Data is a trend that can be briefly described as follows: all the huge data about past performance and work is stored, and can be retrieved then to see how past trends can recur in the current trends, thus helping decide and prioritize. Considering the meta-law of things developing in cycles, this might work, to some extent. There is a certain probability that past trends would help one prioritize efficiently in the present. There’s some financial software developed that calculates those trends. But, from what I’ve been able to see, the big fish and the big gain in stocks usually come at random. This all boils down to the intuitive feeling. Something outside data and calculations. This is not to diminish the importance of data analysis. Any data is a huge asset. Even more this is an asset as we live in the age of information, and we need to learn to get the best of those assets. But, just as the term “project portfolio” has the trace of hope instilled in copying this practice from financial investment to software development, in that it would set us free from prioritization problems, there’s something to watch out with the Big Data trend. Yes, we always strive to put burdens off of our shoulders, as Homo Sapiens, and that’s why we started with sticks as tools, then shovels, and on. Same with the heavy duty prioritization and Big Data. To a certain extent, we can be sure that it would help us move forward, and give more sophisticated tooling for effective prioritization. But ultimately, there’s something even beyond Big Data. Some other infotech miracle. All in all, not that we should lose hope in freeing ourselves from prioritization work altogether, but I don’t think that even Big Data would become the silver bullet for the IT professionals in prioritizing their project choices. We will have to carry personal responsibility all the same. But this would definitely be a step ahead in the evolution of methods and tools for effective prioritization across many projects and initiatives.
Back to the Future of Agile Software Development
Kanban as Multiban?
Software penetrates every pore of human existence. We look up the weather info over the web, giving up on outdoor thermometers. We’re driving to destinations with GPS navigator (forget paper maps with their G7 sections on page 59). We turn on RunKeeper when riding a bike to calculate the average speed and run and boast in Twitter. We’re using software every single day of our lives. It seems we’re hugging our dear gadgets a lot more than our loved ones.
No one knows the exact how-to of writing great software fast, that’s the problem. Waterfall passed away at the crossing of 2 centuries, whereas new software development methodologies (agile) fail at solving the fundamental problems so far. We’re living in very interesting times. Software development industry grows fast right here, right now, and the foundation for a quantitative leap is building up.
1. You don’t waste time on estimation
Estimation takes time. Even if you do planning poker and use story points, it still takes time. What do you do to improve estimation accuracy? You gather some data, analyze the data and discuss the results. You are spending time on all that. But are you sure that estimates really provide any value? Most likely not. It is a waste. You’d better spend this time doing something important for the product.
2. You shouldn’t explain to higher managers why it took soooo loooooooong
If you don’t have estimates, you can speak without fear and explain things clearly. You can enumerate problems and explain how they were resolved. You can show that you work really hard and take all the necessary actions to release this story as soon as possible with great quality.
If you have estimates, be ready to hear something like “you screwed up, maaan! You had to deliver this feature till the end of the month! What the f%$k is going on?” as an argument. The team put themselves on a weak side immediately and have to care about deadlines more, not about quality or a better solution. Is it something you really need?
3. You don’t give promises that are hard to keep
You are not relying on people’s optimism (which is built in). People are optimists (almost all of them) and inevitably give optimistic estimates. You can use complex formulas or very simple rules to have better estimates, but is it really worth it? You can spend many hours defining correct formula for exactly this development team. People will not trust you, since you (rightfully) don’t believe in their estimates. Numbers will look “made up” and still you will have incorrect estimates in the end.
4. You don’t put additional pressure on development team
In some teams Estimate is equal to Deadline. That’s bad. What do you do to meet the estimate? Compromise quality? Tolerate average architectural solution? Abandon polishing? All that leads to poor solutions that end users will not like. It is better (almost always) to spend more time, than planned, and release something really usable and useful.
5. You focus on really important things
Imagine, you have a planning poker session and estimate all stories inside an epic. You sum up all the stories and define it as a 1000 pts epic. You just stick a “fear” label on the epic. People do fear large problems. A 1000pt problem is huge and psychologically it is harder to decide “let’s start it right now”. Product Owner will have a temptation to implement 100 smaller user stories instead of this huge epic. However, it may be a bad decision. This epic may be really important, the morst important thing for the product.
If you don’t estimate it and are not completely sure about its size, you have a better chance to actually start doing it.
Today I’ve read two interesting posts: The Cost of Code by @unclebobmartin and Code as a Cause of Project Failure by @DocOnDev. They discuss various arguments to prove that all projects fail because of code. The main argument is that if code is free and light-fast to change, project can’t fail. OK. But this case is rather extreme and obviously impossible. We don’t live in a world with hyper-space jumps, teleportation and free medicine (unfortunately). In real life code costs a lot and it will be true in the next decades for sure, so this argumentation proves nothing. In ideal world there is no such thing as code. In ideal world you have a solution in seconds without computers, software and other complicated things. So I don’t buy this idea. Code is not the main reason for projects failure in reality.
Code is not free. Code is expensive. We do not sell source code though, we sell solutions. If it is possible to create a solution without source code, it would be fantastic. Let’s take an industry that handles tangible objects. Automobile industry does not sell carbon and metall — it sells cars. It sells a solution to transportation problem. Teleportation is an ideal solution, but we can’t teleport nothing but electrons, sadly. We buy cars to get from point A to point B. We buy a solution.
Code != Solution
I think the main problem with projects is that they provide either bad solution or no solution at all. Nobody buys stagecoaches these days, since there are more efficient solutions. If a project does not solve anything, it will fail. If a project solves something, but in a nasty, unusable way, it will fail. You can create an absolutely beautiful architecture with the cleanest code in the world. You may have 100% test coverage, complete separation of concerns, flat hierarchies and methods without boolean arguments. You may have all that beauty, but still fail miserably if the program does not solve user’s problems efficiently.
You may argue that with clean code you can refactor it fast and change everything. C’mon, it will be a full re-write if it solves the wrong problem. Can you fix a stagecoach to make it a true competitor of a car?
On the other hand, if a projects solves a right problem, but with some issues, clean code is very important. You can’t adopt fast without it. You can’t change things and react to people demands.
Don’t get me wrong, I believe that clean code is an important thing, but it is not the most important asset in software development.
This week’s hot topic is Scrum Alliance. Scrum Alliance dysfunctions were revealed by Tobias Mayer in interview and a blog post State of Agile.
Scrum should not be codified in any way: there is no authoritative Scrum, there is just what we do. Any attempt to nail Scrum down to one definition will be a precursor to its death. The Scrum Guide comes very close to taking the life out of Scrum. The Scrum Alliance-threatened Scrum BOK will kill Scrum, for sure.
I personally see the danger as well. While I understand a desire to protect Scrum from blurring focus, it is also obvious that Scrum should evolve and improve in a very flexible way. BOK is too heavy and slow.
I spent several hours this week improving my hiring skills. Interesting article and even more interesting discussion. I especially liked two questions and most likely will include them into future interviews:
Give me a normalized database structure that you’ll implement if you were to build gmail – incorporate conversations, messages, multiple message participants and labels.
Then, depending on the candidate, I build upon the question,and go into various optimizations possible, the ways caching would be implemented, sharding/splitting/de-normalization would be done with load, etc. etc. With good candidates, its always a very interesting discussion.
This one is a true gem:
My favorite: “Write a script that will save you one minute of time every day”
In Part I I’ve described 5 mistakes in agile adoption, this part has 5 more.
6. CST Knows Everything
Certified Scrum Trainer is not a God. Yes, he knows a lot and has a decent experience. There is a high chance that he may be a capable person to help with agile adoption, but only help. He may know nothing about your domain, about your unique situation and about root problems of your organization. If you rely solely on CST and delegate agile adoption to him, it will fail.
Everything should start from the culture and people. It means everything should start with you. You should share agile values and support CST with all the passion and force you have to make agile adoption a success.
7. Functional Departments Should Survive
You are starting a new agile project. Design manager delegated one designer to the team, but refused to re-allocate his desk. QA Manager delegated several testers, but refused to re-allocate them. Developers sit together, but all the other team members are separated by walls. Sounds familiar? Most likely there is no cross-functional team there, and agile adoption will suffer.
There are absolutely no reasons to keep functional departments and functional teams. People should work together as a team whenever it’s possible. Definitely, when you have testers in US and developers in India, it is hardly possible. But it is just plain dumb to NOT have cross-functional team if everybody sits in the same building.
Cross-functional teams have so many positives, and no negatives. With cross-functional teams you improve communication, reduce functional competition, simplify problem solving, enable ad-hock process improvements and creativity. Again, there is NO reason to work with old traditional functional teams.
8. We Can Live Without Customer Feedback
Agile is mostly about fast feedback. Feedback from customers is the most important. If you build something with wrong methods, that’s bad. But if you build a wrong thing, that’s just terrible. Why? You will have to throw it away later. Regular (and fast!) feedback from customer is like a sailing direction in a bay with reefs. You constantly correct the course based on wind change and other factors. Customer is the most valuable team member and should be treated accordingly.
Extreme programming recommends to have customer on-site. While this is a great tip, it is rarely practical. Still, you have customer available remotely all the time to answer questions and communicate about a product. If you can’t have feedback in a reasonable amount of time, agile methods will not work. You may build a technically perfect product, but yield zero customer’s satisfaction in the end.
9. Self-organization is Easy
Scrum heavily advertises self-organization. Complexity theory has something to say about it as well. Self-organization is based on a set of (simple) rules, non-linearity and interactions between agents (in our case between people). As a Scrum Master you should just set some (widely known) rules, protect the team and expect the team to self-organize. Right? In reality it is not that simple and no, it will not work out. I’ve never seen self-organization working with just a set of rules.Self-organization in a software development team needs more, it needs leadership. I believe that self-organization can’t happen without leadership.
Pure self-organization assumes that a leader will emerge. That’s not happen frequently, in many cases team will stagnate and fluctuate around mediocrity without a leader. Leader sets a vision and pushes team to the right direction. Leader empowers confidence, passion and self-reflection. This leads to self-organization eventually.
What happens when leader leaves the team? In most cases it falls back or degrades slowly. This is a clear sign that self-organization was not there. True self-organized team will keep its values and progress without a leader.
10. False Goal (e.g. Customers asked us to be agile)
If you have a customer who insists on agile process for his project, you should praise Heaven for this gift. Use this chance as a turning point for agile adoption.
Unfortunately, many companies just try to “emulate” agile adoption with a desire to get this contract. They send some people to CSM courses, purchase an agile project management tool and apply Scrum superficially. They do all that without deep goals and culture change. They do all that without passion. They do all that with a false goal. Almost inevitably there will be the following symptoms:
- Sprints fail. Always.
- No commitment.
- Scrum Master assigns people to user stories.
- Testing phase in each sprint.
The result of “false goal” agile adoption is failure and a long-term disappointment with agile software development.
I encourage you to share another mistakes in agile adoption!
They did it again. Companies are making the same mistake during agile adoption over and over again. We’ve made some of these mistakes as well. If by any chance you see something familiar in the list below, read on and find out why it is a mistake.
1. Start With a Tool
It is not always bad to start with a tool. If you want to dig a pit, you most likely want to find a shovel first. You can dig manually, without a tool, but it will take enormous amount of time.
Agile development is something different. A tool will not provide immediate effect and will not solve most of the problems by the mere fact of its existence. Moreover, you will put effort into tool adoption, shading more important goal — agile adoption.
We encounter this mistake quite often. People come to TargetProcess web site, register for a trial, install the tool and try to use it. They start to ask questions and it’s getting clear that they have no experience in agile development neither agile process established. Sometimes they don’t know what a Burn Down Chart is and how to use it. Sometimes they know nothing about iterative development. It happens. The only piece of advice we can give is to get rid of the tool and dig deeper into agile domain: become familiar with basic concepts and try some process with simplest tools like whiteboard and sticky notes. Then decide whether you need a more sophisticated tool.
2. Start With a Process
Starting with a tool is obviously a bad idea. Most companies start with a process. It is a less serious, but a more common mistake. So you read about Scrum, it looks easy initially. You apply all Scrum practices and after some sprints see that development somewhat improved, but not as drastically as expected. Excitement goes away and process degrades.
What are the reasons? Why has it failed? Most likely people didn’t get the core values of agile development. Process is the mechanics, while values are the core of any agile adoption. The first thing any company should do before trying any process is to focus on agile values such as: communication, collaboration, feedback, trust and passion. It is nearly impossible to apply a good development process if you compromise any of these values. As an agile champion you should enforce these changes. Sometimes these are company-wide changes, sometimes team-wide changes, but still it is absolutely required to apply them.
The fastest way to adopt agile is to start with people and culture. I can’t stress this enough. And it is quite obvious! But why so many companies (including ours) have made this mistake? It is blazingly hard. You will have to change culture, and that will be met with a resistance. You will have to change people and most likely you’ll have to fire some of them. It is a hard and complex process, there are not so many people in the world who know exactly how to apply it. Most of us have no such experience and skills, so we fear this change. We try to start with something easier, something we know. We try to start with a process, with a tool, or with hiring an external consultant (which is good, but not enough). We should fearlessly start with the hardest but the right thing.
Agile manifesto is very deep indeed. If you read it carefully and set the principles as a cornerstone of agile adoption, you will success eventually.
3. Development Practices Are Enough
Extreme Programming is a very cool agile software development process. I think it includes Scrum. Many people may disagree, but in general if you do XP fully, you don’t need Scrum. Interestingly, that developers tend to apply technical practices like TDD, Continuous Integration and even Pair programming, but pay less attention to such things as communication, integral team, having customer on-site and retrospectives.
Why is it like that? Developers are techies, and techies like technical stuff, while often disrespect social stuff. Many of them are introverts, they don’t like meetings, they don’t like to chat with people extensively. They do like to communicate about technical things and do that with passion. However, communication with customer is not about Clojure or fancy lambda expressions, it is about business. It’s business problem domain, and it’s not that interesting for them.
Again, agile is more about people and less about technology. Many practices are focused on people. Pair programming makes for more communications between developers. Customer on-site makes for more communications with end user. Retrospectives boost communication about team, processes, etc. It is absolutely required to apply practices that focus on communication, adoption and fast feedback. It is absolutely required to pay more attention to people, improve their skills, improve technical excellence and shift mindset.
4. Scrum is Enough
Is it possible to adopt agile without technical practices at all? No, it is not. However, it is a less severe mistake than the previous one. If you apply Scrum right, you will inevitably decide to try some technical practices at a retrospective meeting.
The true mistake will be to rely on Scrum solely as a process that will solve all the problems. It can do that, but only if you are open-minded and willing to try various things: from pair programming to BDD. Best coaches believe that Scrum should be adopted in tight pack with XP technical practices. This is a good advice to follow.
5. CSM Knows Everything
Certified Scrum Master is not a demigod. Yes, he has some basic knowledge about Scrum, but in many cases that’s just it. He may have no hands-on experience neither strong theoretical background. He should not act as a PM and prescribe what to do and what not to do. Team should decide. The only real things SM should care about are teams impediments and meta-process. By meta-process I mean a set of rules/procedures that allow team to reflect and improve existing development process.
Common manifestation of this mistake is phrases like “I insist we should change iteration duration from 1 month to 2 weeks” or “I strongly believe we should keep doing code reviews”. It might be that he is right, but it does not matter, the language speaks for itself. There should be no “I” in SM phrases, there should be “We”. Otherwise agile adoption will fail. If SM doesn’t believe in team, the team as such will not gel and will degrade eventually.
Read Part II for last 5 mistakes.