What is DevOps? How to explain benefits to the entire organization? How to deal with company culture? Read our most recent story about conferencing week in Italy: Open DevOps – our conferencing week in Italy.
Another practical article about what super simple practice we have learnt recently. You can use it to boost efficient communication across borders – teams. Enjoy reading!
We at RainFellows have strong IT background. We started as excited Java Developers, later became Software Architects, Scrum Masters, Project Managers. We applied Agile and Lean thinking since our first days in IT. And the results showed immediately – our projects (that normally fail in IT) were considered successful by our colleagues, management, customers. And they started asking questions: “What did you do differently?”
Read more in this article: How consultants became owners.
You know how it goes. There is a group of coworkers round the table and they report one after another project status to their manager. Everyone should be interested in work of others but the truth is they just wait for their turn to say their part. The only person who is somehow satisfied in the end is the manager who just got information about project status. Everyone else hates this meeting or at least takes it as necessary evil. Is it possible to do it a better way?
Imagine people really looking forward to that meeting. Imagine people perceiving the meeting as a key part of their work; as a meeting that helps them very quickly, efficiently and collaboratively solve their operational issues. And imagine a meeting that convinces everyone the project continues as fast and right as possible.
How? Instead of reporting status let’s share what we do and miss and then solve issues in pairs based on actual needs – the same way businessmen do their business in 21st century.
How does it work?
First, the focus is moved from “where we were last week/month” to “what we need to move forward as quickly as possible”. Second, the project team works autonomously and the manager, instead of being a micro-controller, becomes a guardian of team values and boundaries of team autonomy, and an active supporter of project activities.
- Each and every participant gives 1-2 minute elevator speech:
- Who I am and what I do (can be reduced or skipped if people know each other well already)
- What we succeeded in since the last meeting and what I can help others with.
- What I struggle and need help with
- Other participants listen to the speech and do their best to help the speaker. They typically offer either their help or contacts in their network who can help. In both cases they do not say anything aloud, they just fill in a referral sheet immediately at the moment they see the opportunity to help. They do it immediately because we usually do not remember much after all the participants give their speech 🙂 The participants fill in a referral sheet also at the moment they want to accept offered help or they just simply want to know more about the shared topic.
- After the round ends, the participants pass their referral sheets to each other. This exchange visualizes all the connections and makes them conscious. There is also kind of psychological effect of accepting offered referral sheet as a gift, as a certain form of commitment. This increases likeliness of subsequent meeting and cooperation.
- After the referral sheets are exchanged the participants open their calendars and immediately plan meetings to share or help each other. A planned meeting in a calendar once again raises the chance the follow-up really happens afterwards.
- The leader of the meeting encourages the participants to connect and pair during the meeting. And s/he actively offers his/her help and network.
The leader and all the participants get synchronized about what is going on in the project and what are the current obstacles. Moreover they actively help each other to go further with the project.
What do we need?
1, Focus on future
Project has to have clearly defined goal (overall goal and the closest milestone) including acceptance criteria. Each and every project member knows answer to questions “What is a good result of the project?” (goals) and “How do we know we are there already?” (acceptance criteria, KPIs). Just go and ask randomly selected team member whether s/he can instantly answer these questions. If not – you know what to do 🙂
2, Autonomous team
Team members (or a team of teams) usually work independently. But hidden potential lays between the units, in collaboration: 1+1=11. When everyone understands the goals and the definition of done then the best way to create really collaborating team is to pair individual members to solve (non-trivial) problems in order to reach the goals. This way we build so called Triades (see Tribal leadership). By working in pairs they shorten work lead time, less likely introduce an error, learn from each other and become substitutable and they also build and strengthen their relations. Eventually, in the course of time we transform individualities to a collaborating autonomous team. You might then see teams, which did not talk to each other earlier, discussing and proactively solving project issues by a coffee machine.
3, Manager = Leader
The leader is the key part of the system. From the original control element s/he becomes a connector and supporting element. His/her most important role is to support team members pairing and to make sure everyone knows answers to the questions above. The leader then proactively removes obstacles that team cannot remove by itself and regularly “changes oil” by organizing regular team retrospectives – meetings where team members discuss what works well and should become a standard way of working and also what to improve. One and only one improvement is then taken into action and implemented as quickly as possible. We take just one and only improvement because we know from experience the more parallel work we start the less chance is to finish anything at all.
Positive side effects
Established relationships and the habit of working in pairs pays off heavily later on when something unexpected happens (which actually happens every day 🙂 When people are used to work together and they know and trust each other they would most likely proactively solve issues together rather than set borders and blame each other.
We know each project is unique, would you share your story with us? – email@example.com.
Sometimes, no matter how exceptionally you do, a development project fails. And even if you apply the best practices in this area. Whether you are customer or supplier, a fixed-price contract most likely sends you on the highway to failure.
Customers need effective and user-friendly product or servie. Suppliers want to build it. But in most cases they both fail. And it does not matter what domain we are talking about.
Do you create marketing strategy for your client? Do you develop new weather sensors? Or do you build software? Watch out – your project will most likely fail – at least statistically.
There are many factors causing this failure, but one of the main root causes is the contract – an interface between the customer and the supplier. Everything starts there, and at the end of the day it is the contract that is evaluated. Let’s take a closer look at what is the evil of fixed-all contracts that we sign nowadays and what is the way out.
Most development projects fail
Let’s take look at software development area since all the risks and problems are visible here. The alarming fact is that the success-probability of Software Development (SWD) projects is pretty lousy. It is about 37% according to the Standish Group [Chaos report 2010, 2012, 2014, 2017]. Does it mean that IT guys are silly or not competent? No, the problem is that we use inappropriate tools and methods for such a task. Most customers and suppliers approach software development the same way as making products (houses, cars, phones). But the fact of the matter is that it is not the same. Let’s take a look why.
As you can see in the picture above, chances of repeatability and reuse of knowledge while designing custom software is much lower as compared to building a car.
Approaching them similarly would be like making the Apollo program (man on the Moon), comprising of research and brand new technologies, in the Waterfall way – describe, design, build just one rocket for the first time and on the release date launch its crew to the Moon. I am convinced this has all possibilities of being a disaster. It was the 11th Apollo mission which finally landed on the Moon with the people onboard. Imagine how many millions try-fail-learn loops needed to be done with the module prototypes and subsystems before they eventually succeeded.
Success in these creative/innovative industries, where SWD belongs, requires quick learn-adapt loops in order to build something as complex as a software based on customer needs. The problem is that we approach it like it was predictable. We try to fix everything inside the contract in the moment when we actually miss critical knowledge.
House of your dreams
Needless to say, it is very difficult to define these customer requirements. And often these really critical requirements are even missing.
If we ask people “Imagine your dream house… everything is possible… what would you like to have in it?” We usually get answers like a swimming pool, a big television, self-cleaning, big living room, etc. But no one says roof, walls or windows! Have you ever wondered why? Because it is obvious that every house has those. Each architect should know it right? And now imagine a customer refusing to accept software because it is obvious that each banking system must also take care of invoicing which was not mentioned in the requirements. Business analyst should have known that…
Mary had a little lamb
And that is not all. Let’s pretend for a while that we are able to define all the requirements for the product/service. Next obstacle is we simply cannot understand them without ambiguities. Do you know the “Mary had a little lamb” rhyme? If we take it out of context – which requirements usually are – what does this sentence actually mean?
- Did Mary take care of her pet lamb?
- Did she eat a whole little lamb?
- Did she eat a small portion of lamb?
- Did she give birth to a lamb?
- Did she have a sex with a lamb?
- Did she trick a naive individual of no consequence? (stock broker’s slang)
As you can see, the requirement sentence can be interpreted in many different ways. Even the ones you would never believe. Imagine thousands of sentences written inside a requirement specification document. Does a reader see the same resulting product/service as the requirements writer?
Why fixed-all contracts then?
So if we…
- need to apply learn/adapt loops that change functionality during product creation
- cannot define clear requirements upfront
- cannot understand them properly
- and thus cannot estimate them
…why do we still use contracts that are trying to estimate and fix everything upfront? Scope, time and price at the same time? I suppose that’s because people who make these contracts do not realize these specifics of R&D projects, or simply they do not know any better alternative. But this restrictive contract has very negative consequences.
Imagine yourself as a supplier who is bound with a restrictive contract that penalizes deviations from delivery. Imagine things getting more complicated (and they usually do). What will you choose – deliver what is needed and risk penalization or deliver what is exactly prescribed? Most people choose the second option, and there we go – lose-lose situation. The customer does not get what he needs and the supplier is blamed for not delivering it. Rework and error corrections can actually multiply the price of the final solution.
It is no surprise that we cannot predict the future and there are always nasty surprises waiting on the way – such as changing needs, technical difficulties and wrong assumptions. This happens especially when contract and estimates are forced very early, in project phase where we do not have much information. Also this restrictiveness introduces barriers into the customer-supplier relationship which precludes them from applying the most important universal practice – continuous improvement. Barriers make learning loops longer and inefficient.
So what shall we do? Simply put, do not contract detailed result requirements. Rather, focus on how both parties, customer and supplier, shall cooperate in order to achieve the best possible result together. This might be a heretical idea to some of the people living in these stories, since common sense says: “If it does not work, we must be even more strict and restrictive”. But being stricter of course does not solve the root cause and just makes the problem worse.
What should be written in the contract then? Definitely a description of the process, how supplier with customer’s support is going to produce best possible result. We put there all the patterns we know that empirically work. What does it mean in practice? Long story short it should contain the following parts:
- Process of production based on learn-adapt loops (iterations) including all project phases.
- Release preparation (vision, business objectives, major acceptance criteria, high level tests)
- Release execution (iterations and partial acceptance)
- Release delivery (deadlines, acceptance)
- Supplier responsibilities
- Cooperate to formulate requirements from user perspective
- Commit to iteration input and have it ready for Demo
- Customer responsibilities, where customer has to be present and for how long.
- Help to prepare iteration input
- Support development within iteration
- Attend Demo and accept/refuse produced solution increment
- Learn adapt parts
- Have common regular retrospectives to prevent issues
- In case iteration fails, or there is significant negative feedback from customer – trigger special retrospective with customer
- Consequences of not following the agreed process:
- Customer does not attend the demo? All demo functionality is accepted by default.
- Any errors discovered? They have to be fixed in very next iteration by supplier.
- Business model
- What to pay for (capacity? per iterations? per requirement? per StoryPoint? …)
- Bonuses and penalties
As you can see this kind of contract is then always unique since it reflects concrete capabilities and constraints of concrete partners, so it does not fit all. But the parts and ideas there can be easily reused.
We managed to develop and sign a couple of these contracts with different customers of our clients. And according to the results and feedback it really works! One of the examples was presented on couple of conferences already (e.g. Leanest 2012, 2013 conferences in Stockholm and Prague).
Let us know if you are interested in hearing more, we will gladly share what we have learnt.
For every team, in order to fulfill their mission – to satisfy their customers and stakeholders – it is important to stay focused on the value and continually improve the way of working. Having a Mentor can help in both and what’s more, it significantly boosts team’s productivity and efficiency. Let us have a look at three ways how the Mentor can help.
Mentor gives you external perspective so you don’t get stuck in a rut
Things look different when you are inside or outside. When you do a job it is difficult to stop, step back, forget everything you have learnt and take a fresh new look at what you do. A mentor gives you another perspective – especially by asking questions you wouldn’t ask yourself otherwise. Answering them honestly helps you to not get stuck in a rut and move forward.
Mentor brings experience and helps you apply it in your specific environment
Why to reinvent the wheel when you can accommodate someone else’s experience? The mentor shares stories about how other teams did your job, what problems they encountered and how they coped with them. He helps you to apply this experience in your job via training and hands-on coaching – all in specific context of your team.
One good example is daily Scrum meetings. Every team needs to be synchronized and identify and resolve problems as soon as they appear – no doubts about that. But implementing daily Scrum meetings by the book in a team of 15 people working on five different areas in a distributed environment might be a nightmare without previous experience. It can take a long time and can result in frustration of the team when they are forced to do something they don’t see value in.
An experienced mentor helps the team to understand the principle behind and take a shortcut when implementing it in their specific environment (e.g. how often should they meet, how to prepare, what questions to ask and what tools to use). This makes the implementation faster and smoother.
Mentor helps to align differing views of managers and workers to make them pull the same rope
Although both workers and managers are members of the same team and should have the same goal, their views often differ. Workers see the details of their job and concrete obstacles, while managers have more high level view – goals, strategy and dependences. Both perspectives are equally important and need to be merged. However, in practice they rarely meet. So despite both workers and managers are doing their best, they are not pulling the same rope.
Managers are often too busy or too far from the workers’ job
Managers often do not have enough time or comprehension of workers’ job to explain to every worker how does the chosen strategy affect her job and what exactly is expected from her. Or why her problem cannot be fixed now because we have more burning issues on the table. Or why a certain improvement idea cannot be implemented, although it would bring huge return on investment, because we are simply not making enough profit for such an investment right now.
Workers are often left with a simple “DO” or “NO” without “WHY”, which is very frustrating.
Workers are busy as well or think it is not their job to think
Workers, on the other hand, are often too busy with details or think it is beyond their responsibility to ask and try to understand the bigger picture. They prefer to “stay in their box.”
They often do not understand how they get affected by the strategy, what exactly is expected from them and how the whole chain they are part of works.
Therefore they cannot understand the impact of what they do and what they demand on the whole team and its customers. They do not see that by getting rid of “their pain” they can cause pain to someone else in the chain. For instance that demanding “doing things right” here and now (e.g. “the right testing”) could result in delivering everything so late, that customer will refuse to pay and there might be no business at all in future. Or that by not documenting their work they cause troubles to the future maintenance team.
Such a lack of context awareness makes it difficult for managers who need everyone to actively contribute and cooperate towards the common goal.
The Mentor helps both sides to better understand each other and work together
The mentor talks to both sides, thus understanding their perspectives – plus having an external one. Therefore he acts as a natural bridge between them.
He brings up-to-date information and “WHY” to the workers, helping them to better understand the big picture, their role in it and consequences of what they do.
He helps them to better formulate their ideas with respect to the needs and constraints of the managers (shifting their mindset from “my problem” to “our common goal”). The ideas are then more likely to get supported by managers and implemented.
By explaining the big picture again and again and focusing workers on the common goal, the Mentor helps managers to increase workers’ willingness to contribute to the effort necessary to implement the strategy and achieve the common goal.
Last but not least, the Mentor helps managers to understand what are the workers’ biggest concerns and pains, how they perceive the overall situation and how they feel about it, so the managers know how well their strategy is understood and followed and in which areas they need to communicate more.
All in all, the Mentor is your team’s best friend
The Mentor works as an information carrier, being the glue connecting the details and the big picture and making the whole team pull the same rope. He is your team’s thinking partner providing external perspective and experience. And he is always on duty to help you to not lose sight of your purpose and goal and to improve continually.
Do you have one? Would you like to? We are here to help.