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.
We live in the age of added value. It’s everywhere. Value-added services, value-added products, value-added goods etc. etc. etc. Actually, so much value has been pumped up in our life, that it’s even strange that this value is not protruding from us like clothes from an overly packed vacation suitcase.
If we take a closer look at the back side of added value, a huge surprise is waiting there. The example I find most notorious is cell phones. What if I want a simplistic cell phone with NO Internet, no camera, even no voice mail, just live calls and SMS? You’ll never ever find such a phone.
I bet that a phone manufacturer who stops the rush for more new features, would make a fortune in an instant selling the “new frugal” cell phones. In this case, the added value is content which comes from Internet, capabilities to exchange content. Why should someone want a phone without Internet? My word, very soon we will see such phones on the market. The niche for them is already there. Here’s why:
More content and more various channels to produce and exchange content is now commonly presented as added-value. Hence, a communication device which happens to be a humble phone is supposed to deliver this value. But as we’re oversaturated with content, no buzz is a huge deal. The luxury of focusing on one thing at a time is something that only a few can afford. Besides, it’d be very frugal (frugal is actually the new buzzword :) to buy a phone for a reasonable price, and sell a used iPhone to some geek. Oh, pardon me. It’s all about iPads now :)
There’re plenty of such examples. Another one: the added value of having a car means lack of natural movement, the necessity to pay for gym etc. It actually brings along the whole array of more added value goods and services that turn out to be not of added value but of less value, since you pay for what you could do naturally.
Take organic products. Now they’re added value. 100 years ago who could have thought that something natural adds value? Now it’s a rollback. What is simple and natural costs more, but has less value compared to the original added value concept for the matter, and the cycle goes on and on.
And we’re nailing it down to our favorite: project management tools. Versatility and too many features now have bounced back to the simplistic Kanban board.
It looks like it’s time to not only practice lean production, but to produce lean products. Gaining focus requires focused tools, one way or another.
If we think about conferences in general, the traditional understanding is: people come together to share their knowledge, to learn, to discuss, to network etc. Some people expect that if they attend a conference they for sure must learn something totally new, something that will change the way they work or even their lives. Some people come to see who’s out there, to network and to have some fun. In a nutshell, as many people as many reasons to attend conferences :)
I tend to think that with all the information we’re consuming, it’s very hard to come up with something totally new to a thinking and knowledgeable audience. If you’re engaged in agile community, and if you’re a thinking person, you thrive in the blogosphere and you practice agile - it’s hardly that something will be totally new to you (“totally” is the keyword).
Recently we attended Agile Central Europe conference in Krakow. I’d say that my #1 enjoyment about this event was live cross-twittering. Broadcasting Agile CE to the Twittersphere has really been fun. I liked tweets by Andy Brandt, Marc Loeffler (aka scrumphony), Pawel Brodzinski and Robert Dempsey (for the two latter, it’s not only tweets, but their presentations that I enjoyed) . As opposed to most attendees, I didn’t very much like the closing show by Gwyn Morfey and Laurie Young. The guys have done a great show, but it was more about dramatic presentation of what’s going on in any dynamic agile team :) I’ve seen a bit of those “paper sword fights” :)
After attending Agile 2009 in Chicago, I’ve really got a little bit skeptical on the conferences overall because what I’ve seen was people talking about simple truths but with such an air as if they were uttering epiphanies. So, when going to Agile CE I wasn’t expecting epiphanies. It was more about going out there with our team, watching people and taking every opportunity to enjoy everything that comes up on the way (including live jazz night in Krakow).
This approach worked better than huge expectations. Strangely, this small cosy conference has become an unexpected source of inspiration. In a sense, that it’s not always you have to come up with an excellent new topic or idea no one else knows about. The main thing about conferences is confidence and freedom to express yourself, share your personal experience and absorb experience of others. Somehow someone will find it useful. There’s no need to be afraid to appear too simple. People will listen and admire even if this is your first experience as a speaker.
And.. it’s great that there’re many more agile conferences to come :)