Imagine a project with hundreds of people, a lead time in months, few releases a year. You could compare these as large cruise boats or tankers navigating for few weeks in the immensity and emptiness of the oceans and seas and then stopping to ports very far away from each other. While at sea, or during the build phase, contact is difficult, and you are far away from customers and rescue.
As a Coach, Scrum Master for a Scrum Team it is sometimes difficult to find ways to inspire people and give them a goal to strive for. Most of Scrum Teams have been trained to use Scrum, they have people helping them to apply it but do they really understand the implications of all this?
Scrum or not, companies organizes team buildings for teams, project, groups in order to bring people closer for years now. It is not because it is fun, it has a cost obviously, but we do that because we know that successes comes from motivated group of people. So in order to get better outcomes from a Scrum Team we need to give them an idea of what it means to be a high performance team, not just another team.
High Performance Tree
Few years ago I discovered this video from Lyssa Adkins, very simple but extremely powerful.
In only few minutes by drawing this tree in front of your team and explaining them what it means to be a successful Scrum Team you can get them inspired. Then you can talk about all the attributes of a High Performance Team with them and probably discover more. I encourage you to do it, not a waste of time really.
Either you are a Scrum Team Member or a coach the Values Retrospective can be very powerful. As you probably know at the end of each Sprint we run Retrospectives to inspect ourselves as a self-organized and cross functional scrum team. After few sprints if you don’t have the proper mindset in place you will face a zombie scrum team doing mechanical or flaccid scrum. We definitively don’t want that. I won’t go into the many ways of trying to get back on track with a team like that, but a starting point can be to inspect how we are doing with the Scrum Values.
Reboot the values
Start the meeting by covering the 3 pillars and the 5 values. If you are facilitating, don’t be the only one to speak. Timebox the discussion for each value. Ask the audience what means each value for them. Ask them to not try to inspect the current state of adoption but really what this value is supposed to mean for a Scrum Team.
Evaluate Values Adoption
Ask everyone to evaluate each value from 1 to 5 for example. You can do that on paper, with fist of five, online with a shared tabular sheet… Your choice.
Then ask the audience to rank the values. Which one is the one we totally adopted which one we have the most difficulties to apply to ourselves. You can rank them from 1 to 5 or use any other way.
Discuss the Results & Take Action
Sum the results for each value and look at the one you need to work on the most. This has to be a discussion but don’t forget to come out of it with at least one concrete action to take immediately.
In the past years I had the chance to support, train, teach and mentor many teams in adopting Scrum and agile practices. I have seen many organizations, departments, group of people with various point of views regarding agile. Most of the time people around are skeptical and doubtful about bringing more agility in their environment simply because it is different than what they are used to. Thankfully after trying it, a large portion of people, even the more skeptical realize that they can’t come back to where they were before. When people realize this that mean you probably have made an impact.
I consider our job as coaches to impact organizations. When we come somewhere we should assess the current state of things around and measure what is changing weeks after weeks. They open new jobs for Product Owners, they hire an internal coach, the workplace changes, many visible signs you can track. Having teams delivering value to their stakeholders is something but that is not it. If you consider your job done when an increment is in production you probably missed the point. Our job is to bring people together, break silos, activate new channels of communication between people who weren’t talking together, give people autonomy, drive them to the path of mastery and create a supporting environment for all those changes amongst a lot of other things.
I was and still am a .NET Developer. I did many internships during my scholarship, then worked in small to large projects. I was quite happy and an innocent dev until I became team lead and had to spend my day to break down chunks of work for my team, do PowerPointS to justify changes to my client, report to the project managerS, report to other middle management. Lot of new things that made me realize my job would be boring from this time. Frustration was building up until I resigned because of a bad manager.
One day I was getting out of a job and my community lead decided I will go on an Scrum Training for a week. I came back from holidays and went to it with a vague idea of what it was. After a week I was transformed, literally. I loved my job again.
Since then and after years experiencing terrible and successful agile my first objective is to have people having an epiphany and help them realize they can also change things in better around them or at least try.
This article is not for Product Owners as they must follow this training. I want to encourage Scrum Masters, business analysts, testers, developers to think about following this course.
From PSM to PSPO
My agile journey started with the PSM and PSD courses a few years ago. Then I became a Scrum Team member for some time and didn’t feel the need for more training. But when I started to become a full time Scrum Master I realized I needed more tools and practices to help my teams and specially the Product Owner and the organization around. I was facing questions like: how can I order my backlog? What are the key measures to show to management? How do I build my vision as a PO? And many others. Like many I started googling things and did my best to find and forge my tools. I quickly wanted more than that and went for a PSPO training.
Professional Scrum Product Owner
Like the PSM, the PSPO training is a 2 days course. As usual with Scrum.org the content and the structure are perfect and even with few years of experience using Scrum, having a people around sharing their own experiences and techniques is of great value.
Besides that, I came out of the training with a new understanding of the Product Owner job. She or he is not only the person with the vision we all think of. She is the captain, the leader, the beacon of one to multiple teams like a startup entrepreneur. It is a difficult position that needs a lot of support, empowerment, natural leadership and a very pragmatic approach. From the Scrum Team member point of view, you only see few aspects of the job and this is why we lack understanding of this role. For two days you can be in her-his shoes and see what you would do in some situations.
I won’t give you a list of all the practices you will cover but here are some of them: Impact Mapping, User Story Mapping, Key Value Areas through Evidence Based Management. Anyway except if you have a large agile community around you those trainings will bring you more than you think and remember how great was your PSM training experience and you’ll want to go to this one.
Starting your agile journey with a Why question is a good start. Why does it works and what do you need to make it works ?
Scrum is an implementation of empirical process control and this simple fact tells a lot on how it can be successful. When you are building a product in a predictive way you are trying to prevent all scenarios that may cause you problems in building and delivering it on time. And most of the time it fails because of the complexity and the challenges you face. And also because we never take time to look at our issues and find ways of fixing them in a longer term. No lessons learned just firefighting.
If you do it the right way you need to make the three pillars (Transparency, Inspection, Adaptation) the foundations of every decision you are making. This way will allow you to constantly analyse your current situation and adapt in consequence. Every problem you are facing is a learning experiment that you can transform into small adaptations in your process. As simple as it is.
But what make scrum teams successful?
If you choose to go the Scrum way and want your team to be successful you will have to do more than just implementing the three pillars. The five values are the roots for your team to grow and perform. Those values are too often forgotten and this is why they reappeared in the Scrum guide in 2016. Respect everyone, be committed as a team in your every day work, have the courage in taking decisions and try new things, be open and keep your focus on the goal is what it should be all about.
All in all Scrum is not a magical framework but helps you through a simple set of roles, events and artifacts to start building software in less than 30 days. Every iteration is an opportunity to measure and learn in order to deliver the best possible product that fits your business. But don’t forget that having experienced people in Scrum implementation and the right training will help you to start in good conditions. Now Scrum On !
“I want my teams to become more agile in order to save money” is probably a sentence you will hear a lot from financial directors and executives. Is this really a myth?
Where Lean is not really what we should be looking for
This myth is often related to a misunderstanding of the relationship between Lean and Scrum. The Lean concept is about maximizing value and reducing waste. If you don’t associate both ideas you are not going to get results. Most executives like the idea of reducing waste and so the cost while getting more out of people. By the way in this scenario we don’t talk about people but resources. So sometimes when you have to assess a team to find ways for helping them going out of a flaccid scrum implementation you also have questions like : who do I need to fire once they get better?
Waste should not be related to people but instead it should be on ideas, vision and value. The whole point of agility, lean and so Scrum is to maximize the value of the product we are building. Finding better ways to deliver better software and not finding better ways for cost cutting.
Saving money : not the idea
What matter the most is to deliver value rapidly but what is value? When you get asked about how we a company can save money doing agile you should reply saying : what can we do to get more money out of your product ? By getting more money in selling a better product we move from the idea of saving money to survive to gaining more to expand. If you want to bring the conversation on this field you should be prepared to answer a lot more questions about defining the “what” of the product. There are a lot of ways to make the value a tangible actionable metric. You can start by monitoring usage of features, product, do user surveys or even analyze how much money you’ve spent to build your minimum viable product. Only having a number between one and hundred is not enough you will have to quickly move to a value coming back from a real use of the product.
Teams of highly qualified professionals
Forming agile teams is where you’ll probably realize that becoming agile is not costless. Specially at the beginning. The best agile teams are for sure made of highly qualified professionals with a lot of experience. As you may know we are looking for self organized and cross functional teams so if your team is made of interns with no experience you are in a dead end. When people are more experienced they are usually more expensive and this is normal specially if they have the expertise you are looking for to build your product. You can build agile teams made of experts and junior but it won’t be as effective as having only experience people.
In summary move the discussion to business value delivered instead of cost. A better time to market and building a better product is not something you can do with small teams of inexperienced people. So find ways on getting the best possible product that can make your business flourish in small but effective steps. That should be all what matters.
What quality means for Developers (please read Testers, Analysts, Dev, Ops…) in an Agile team is definitely an endless talk. I could write tons of lines about it but I can also tell you that having the discussion is an excellent start. Too many teams rely only on the process and not the practices. In Scrum for example we do not prescribe any engineering practices but the most performing teams are implementing a lot of them in order to deliver a high value product on a long term basis. It’s a fact.
So, how do we define quality ?
If you look at Clean Code‘s first pages you will see this : “The total cost of owning a mess”. Please read it, print it, sign it and display it on your wall. In only one page and one chart Uncle Bob sum it all. We have all experienced this in projects once. When we start compromising the code maintenability to be faster in delivering features. Until it’s too late to fix the mess. In agile projects we call this technical debt. Technical debt is a whole, not only the fact that the code is a mess. In general, when you have some the product backlog is also a mess in general. So, quality is finally a sum of good technical choices taken at every step of the software development. As a team it’s your responsibility to envision your architecture, take time to think of every choice but also admit the fact that it will evolve, move, live.
My Basic definition of Quality
A Working Software continuously delivered to Users
Good Technical choices implementing a maximum of the quality attributes : extensibility, maintenability, testability, security…
No tolerance for bugs in production
Being able to manage the debt
Don’t forget the principles !
Back to basis. Do you remember the agile manifesto? Yes you read it once. Now let’s look at some principles we probably forgot that will help us regarding quality.
Continuous attention to technical excellence
and good design enhances agility.
Simplicity–the art of maximizing the amount
of work not done–is essential.
The best architectures, requirements, and designs
emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts
its behavior accordingly.
In a following post we’ll go deeper in those principles and see how difficult it can be to implement them.
Feel bored working on legacy code? Spending your day working on old frameworks and codebase? Implementing functionalities that are not asking more than 2% of your brain? No challenges in what you are doing? Ok I’ve got you covered. The web is full of fun ways of practicing and reactivating your neurons while coding.
Probably the largest online community to practice and improve your coding skills. You can find dozens of puzzles to solve with various levels of difficulty. The cool thing here is you can play against people and enter into leagues.
Start with some simple puzzles to understand how it works.
Use your favorite platform (Visual Studio, Eclipse…) to take advantage of the intellisense and simply copy/paste your code into the codingame interface.
Have good fun programming bots : Code Buster & Tron are my favorites !
Take a break with your team and compete with each others around some bot programming. You just need to follow each other and show the leaderboard by filtering on people you follow.
RISE is the acronym for Microsoft Research in Software Engineering based in Redmond. They developed pex, a simple tool that automatically generates test suites with high code coverage using automated white box analysis. They are basically working on innovations that will impact our work as programmers. Huge commitment!
To entertain us they provided some good sites to practice around their researches. My favorite is definitively Pexforfun !
When you start working on agile projects you realize the most difficult part of the job is to convince people. You are basically swimming against the tide on a daily basis. Exhausting. But if you don’t have the right answers to their questions it makes things even worse. So let’s try to build ourselves the right discours.
Agility is a part of our everyday life
A lot of things around us are what we could call “Agile”. The foundation of agility is empiricism. You try something you get a feedback and then you adapt to the situation. You simply use the feedback to progress in the right direction. That’s it.
The Hotel Shower
For example when you arrive in an hotel room for the first time and you want to take a shower. You don’t know at this time what will be the temperature of the water coming outside the pipe depending on how you have adjusted the faucet. So you try and you measure the temperature with your skin then you adjust again until you find the right one. This is empiricism !
Now let’s look at the same situation from a different angle. This time in a sequential (waterfall) way of doing things. First you need a faucet that delivers an average temperature of 38 degrees Celsius. You go and ask someone to build one. You install it and then you open it and you realize it is way to hot for you. Back to square one, unmount it, back to your vendor and ask him to change it to deliver water at the temperature of 36 degrees Celsius.
I will let you imagine the time and energy spent across the entire process. Without mentioning the frustration. In this first simple use case it is clear that we need to adapt from what we measure and we need to do it as fast as possible to avoid accidents.
The Traffic Jam
Another example this time with traffic in big cities. Today a lot of roads are jammed with thousands of cars coming in during the rush hours. Now let’s imagine for a second that all the cars and motorcycles would be trucks instead. See how it could turn to be a nightmare ? And now let’s say they are all motorcycles. How much smoother the traffic would be?
In Paris we have a lot of traffic jams during the rush hours and during those hours you can see hundreds of two wheels. This is because most of us realized that it was much faster to go between the lanes with smaller vehicles. Again a simple inspect and adapt process that we applied to our every day lives.
So now, just pick a story your client can identify himself in and tell him how much better it could be to change the way his products are delivered. And again keep this in mind : start small.