Manage Agile 2015 sponsored by agile42

/by

Manage Agile 2015, the conference for agile managers and those who want to become, takes place from October 5th to 8th 2015 in Berlin for the fourth time. The conference is divided into two workshop days (October 5th and 8th) and two conference days (October 6th and 7th).

The conference is focused on Leadership and organisation, Economic aspects, HR management, Agile project- and requirements management.

Manage Agile 2015

The topics are completed by numerous use cases from Siemens Healthcare, Siemens, Otto, Capgemini, eBay, Continental, The Boston Consulting Group, Zalando and many more. and there will be an accompanying exhibition with renowned consulting- and product companies from the agile field during the two conference days.

The Manage Agile targets management topics – no pure technologic aspects. The Manage Agile became a networking platform where specialists and managers compare notes yearly to establish agile topics not only in software engineering but also in the whole company up to the management.

agile42 is extremely happy to be a repeating sponsor of the event. This year, our strategic coach and founder Andrea Tomasini will deliver the keynote Stop scaling… Start growing an Agile organization on October 7th.

agile42 offers a 10% discount to members of its community, please contact us if you plan to attend in order to obtain your code.

Meet the Coach: Roberto Bettazzoni

/by

Following up on our semi-monthly agile42 newsletter feature titled “Meet the Coach”, we asked some questions to one of our coaches from Italy, Roberto Bettazzoni. Thanks to his solid programming background Roberto often coaches development teams starting with Agile or DevOps techniques. He is one of the leading figures in the Italian DevOps community, and he recently co-organized IDI 2015, a one-day event sponsored by agile42.

What is your background and how you started with Agile techniques?

I have a technical background: I started programming in high school, I wrote my first commercial program when I was a freshman at university and since then I’ve always coded for work… and I like it. In the years I discovered that I appreciate teamwork and help others to code. What I like most in my work is learning new things.

Regarding Agile techniques, I don’t have a clear answer, because at the end of the 90s, or maybe first years of 2000s, the techniques that we now call “Agile” were not seen as linked: we used unit testing, refactoring… because they were the most efficient programming practices. The first time I heard the adjective “agile” applied to software development has been in 2002 or 2003. In particular I remember the XP2003 conference in Genoa where I discovered eXtreme Programming (XP) and Lean software developments practices from the authors in person. So I decided we needed to test XP as a methodology and I persuaded an Italian firm to try it while developing a solar electrical plant monitoring tool. It was a success and that software is still operational.

Roberto Bettazzoni at IDI 2014

You have recently helped kickstart a new team at a startup, what do you think it’s needed for a proper Agile approach on a new project?

Now, as in the past, what is needed are knowledge and team effort. Development of software, especially modern software, requires a variety of skill sets and, even if members of your team hold a number of them, it’s nearly impossible to deliver something when you’re less than 4 or 5 people. When you have very skilled people that work together, efficient communications become fundamental, and misunderstandings and tensions inside a team are very dangerous. In this light, my opinion is that nothing is more important than transparency, everything should be accessible to allow a real “informative pull system”: everyone should have access to all informations in order to check, discuss or edit.

DevOps and Agile, is it a perfect match or something that needs to be further developed?

We are just at the beginning. DevOps is a movement, started from specific needs but so far it doesn’t have a clear identity, also because, in my opinion, such a definition could not exist. There is a technological common thread between virtualization, parallel testing, continuous deployment, microsservices, low-cost scaling IT infrastructure, SaaS, PaaS or IaaS … the technological links are quite clear, but I don’t see yet some “value” or “method” that can glue together this technologies and practices.

Moreover, the DevOps world needs to overcome cultural barriers originated by the prevalence of individual work over team-based efforts. Anyway a community is forming, gathering around practices and tools. Somehow it reminds me of the Agile movement at the beginning, because at conferences you can feel a sharing spirit, looking for working solutions and the “what is needed to solve our problem” attitude, that is a bit lost now in the Agile community once the movement got mainstream and started to be adapted to different needs (and I should stop here because I don’t think it’s politically correct to say “corrupted by incompetence and by big companies”). Price of success, because currently Agile is the only sensible way to develop software.

What is a recent technology, or development, that you got interested into?

In the Agile area I’m interested in how to optimize the Continuous Delivery practice in Scrum. It’s not so obvious when you have teams that continuously deliver value directly to the customer. The testing and the review phase is challenging, but it works and it gives a great advantage to the customer. On the tech side, I am constantly interested in development techniques, at the top of my list right now I have [micro]services orchestration and functional programming.

The orchestration of services rose some year ago as a need due of the great number of processes and services running in the enterprise level software. I first meet the problem 4 years ago with a massive parallel testing environment. Now the virtualization and Docker allows to have hundreds or thousands of  small and specialized services (microservices) to form a complex, scalable and reliable enterprise system. The problem is the orchestration of all the system. 

Functional programming is something quite dated and an old passion of mine that never died. Nowadays, thanks to new efficient languages with high-level powerful semantics, it has become very interesting and ready for mass adoption. I find it a very good solution especially for designing the microservices I mentioned.

Looking for the perfect recipe

/by

agile42 has a tradition of visiting Vito’s for our company dinners (that’s Vineria Fraschetta in Friedrichshain in Berlin, for those not in the know). We of course enjoy the cozy atmosphere and interesting discussions over some bottles of Sangiovese. Then again these ingredients can be found in any restaurant. We come back to Vito’s every time, because he is an excellent chef — a formidable wizard when it comes to italian food.

Each culture has its own recipes. There are Italian recipes, French recipes, Indian recipes and so on. But there is no perfect recipe, as each culture has its own peculiarities, taste, spices etc. No one is trying to convince Italian chefs that they should use Indian recipes. However they could definitely look at them to get inspiration and introduce new dishes. They adapt them to their context and culture.

Looking at how we drive organisations, you will quickly realise that most of them are looking for the perfect recipes (aka practices, “best practices”). Show us the methods and tools we should use, define which roles, activities and artefacts should be introduced and we are done. Give us the right recipe, and we will apply it and then magically become the next Google, Toyota or whatever.

Indeed there are no other Googles and Toyotas out there. Both companies are unique in what they are doing and just trying to copy their process and/or using their tools will have little effect. It’s not so much “how” they do things, rather it’s the shared purpose, the mindset and attitude of their people that makes the difference. The “how” changes continuously as the world and the business climate is changing.

Some organisations are obsessed with tools. The thinking goes that if you get the toolchain running, people will have to follow the new processes. For instance there are still people that think that reducing waste or applying Lean Six Sigma is the only thing you need to do to become Lean.

Many realise that culture is a big part of the equation, and so they try to instill/enforce the new one. By trainings, by processes and tools. This will not work either. Culture change cannot be teached and it does not happen magically by using a new practice or a new tool. As Peter Drucker famously said, culture eats strategy for breakfast.

Many companies underestimate the cost and difficulty of the transition, how hard it is to keep the balance between stability and change. Some go for a big-bang approach, a quick disruptive change, others are hesitant and slow. In either case, gravity (culture) and friction (resistance to change) tend to drag back the system to its previous state.

In essence, there is no single recipe. To create a good meal, you need to understand basic food chemistry and how the ingredients and raw materials react together. While beginners may benefit from recipes, the best chefs have honed their skills through years of experience and document their recipes only for information sharing and brand building.

Similarly, when creating a good organisation you need to understand the basics of how organisations work. You need to focus on why you are changing. i.e. identify either goals to work towards or sources of dissatisfaction (pain points). You need to understand principles and values behind the methodologies and approaches you are going to use. You need to evolve your own organisation by being different, not just by adopting new processes and tools. Again beginners may benefit from recipes, but going anywhere beyond that means that you must learn and start utilizing the basic concepts.

Photo of Vito of Vineria Fraschetta by Karolina Rosina

Our friend Vito is the master when it comes to Italian food. He knows the rules, and when to break them. He doesn’t necessarily follow any recipes… he follows his nose! And we like the results.

Photo of Vito and Vineria Fraschetta by Karolina Rosina

 

Executive Panel Discussion at MHA2015

/by

agile42 has sponsored the Executive Panel Discussion at Mile High Agile 2015 on April 3 in Denver. Thanks to the organizers, the video of the panel is now available in its entirety.

The theme was Building and Sustaining a Lean-Agile Organization, the five panelists are: Brian Warden, IT Director at Nelnet, Rick Newman, VP of Engineering at ReadyTalk, Mark Curry, VP at Oppenheimer Funds, Eric Kihn, Director at NOAA – National Geophysical Data Center and Susan Courtney, Senior VP at Blue Cross Blue Shield Nebraska. The panel is moderated by Brad Swanson.

Are incorrectly applied KPIs the root of all evil?

/by

We have all heard it before “show me how you measure me and I show you how I behave” (I think the original quote is from Eliyahu M. Goldratt). It’s been quoted and requoted so many times it’s hard to tell, and it’s true.

I see the effects of this issue every day, which leads me to ask the question…

Are incorrectly applied KPIs the root of all evil?

I see dysfunction in organisations all the time, as do many people I am sure. I often ask the question, “is that part of your KPI’s?” The resulting answer “yes” just reinforces this more often than not.

I was speaking to the product owner of an interesting project. He was complaining about the number of bugs logged that were essentially duplicates. I asked how the testers were measured, and he said “bug counts.”
It feels to me that KPIs are trying to solve multiple problems, and that we have lost sight of the goal of encouraging a behaviour of self critical improvement, instead of informing a behaviour of compliance.

Trust / Performance

The first problem I see, is that people don’t trust each other to do a good job or rather that organisations don’t trust the awesome people they hire. We create performance bonuses and remuneration around objectives, because we believe that people need external motivators to get work done. There is an underlying belief system that says people need carrots and sticks in order to be their best. I believe that if you give people a clear common goal, and the resources to achieve that goal, remove the impediments, then they will try their best to achieve the goal, regardless of bonuses.

Instead we link specific outcomes to people’s value.

By doing this we are essentially linking their value and success in the organisation to these KPIs. People want to feel like they are adding value. The resulting behaviour is that they will do everything in their power to achieve the stated KPI outcome. This, in and of itself is not a bad thing. The problem arises when this goal is at odds with another person’s goal (or KPI) or with the overall business strategy. How we set these up is part of the problem.
Creating an environment of visibility and openness is a far better way to encourage trust and performance. People will more often than not do their best to be committed to a team and to deliver on what they have promised. No one wants to be the person that let the team down. A collaborative team environment that encourages honesty and trust is far better than a group of people with conflicting goals. Rating people individually while trying to foster a team culture will likely create dysfunction, competition and unhealthy conflict.

Lack of direction

Closely linked to the lack of trust is a lack of direction. What I see is that companies have not clearly defined their strategic objectives and created a clear common goal for the people in their organisation to move towards. Setting up Global KPIs as an indicator of progress or as an overall goal, makes more sense to me than individual competing KPIs.

An example of this I have seen is that, we have 100+ projects that need to be delivered and no clear alignment about what we are trying to achieve with these projects and which ones are most valuable to the organisation. Project Managers are rated on getting Project X in on time and this is linked to their performance bonus, whilst teams need to deliver on all 100 which is frequently an unachievable goal. Teams are forced to make priority decisions on a daily basis about what is the most important thing. They make these decisions while lacking valuable context and information.

How the Project Manager or Project Sponsor is rated, drives her behaviour. She will do whatever it takes to make sure that Project X is delivered on time. If Project X is not the best for the business, that is not her focus. If Project X gets executed poorly and shipped with loads of bugs, that is not her primary concern. The KPI was to get the project done on time and that will inform her behaviour, her goal is to add value and meet her targets.

By setting her KPI and linking it to a monetary incentive, we are basing her value and reward on a single goal over which she has no direct control. The resulting behaviour is to conceal the truth about progress, to compete with other project managers or project sponsors, and to not always share valuable information, especially if it does not serve her end goal. This has large impacts on the global strategy that most people are unaware of.
Setting a clear, common goal and ensuring that people have the necessary resources (yes, I mean actual resources) to achieve that goal is far better than creating competing KPIs. Setting goals that align to business strategy across all areas will help teams and individuals make better decisions about what to do next. Giving those individuals enough information about where we are going and why we need to get there will encourage them to work smarter and with more collaboration. So it seems that this starts with better prioritisation and alignment at all levels (Brad Swanson has a great post on this).

Creating Competition

Some organisations believe that creating competition between divisions and departments is healthy and that it helps the business to grow. I have seen instances where this has created a large amount of dysfunction. What often happens is that each division has KPIs that compete with other divisions, except of course the service departments, like “IT”, who often have to service all of these divisions, and generally at the same time.

Now you have different divisions vying for “resources” (if you’ll excuse the term) and the result of this is that each team member is 20% allocated to this and 30% allocated to that and 45% allocated to the next thing, and 5% allocated to learning. These individuals spend their days context-switching between competing stakeholder requests or in project update meetings. Likely less than 50% of their work day is spent doing the making that everyone is hoping for. As a result, each person is actually only able to contribute minimal time to the project. The transaction costs are so high that it ends up taking years for a team to ship anything.

Having alignment is better than competition, especially when there are only one or two teams that can deliver to the business. If the Project Managers and Product Owners are aligned in their goals, then it will be much easier to ship the most important things, because it will be easier to get focus for the teams on one specific thing. Setting people against each other will only result in more context switching and higher transaction costs. The knock-on effect is that everything takes longer to get done.

The current incarnation of KPIs is NOT, I believe, effectively solving the problems we want to solve. We pit people against each other and encourage them to compete; for time, for resources, and for people. We create environments where people are fighting to get their needs met and not for the overall needs of the business. In an environment like that, it is the loudest person or bully that will win every time, and that doesn’t always make for the best business decisions.

According to Gerald Weinberg, it’s useful to apply the rule of threes when thinking about any problem. Gerald suggests that if we can’t come up with at least three ways to solve the problem, then we don’t understand the problem effectively.

Perhaps in the case of KPIs we have lost sight of the problem we were trying to solve.

Some organisational KPIs add value and direction. At agile42 we use KPIs to help create focus, direction and self critical improvement. The current incarnation of KPIs in most organisations is reinforcing the dysfunction and not solving the right problems. We apply KPIs as a solution to create performance goals because that is the way we have always done it. To quote Gerry again “Things are the way they are because they got that way”. Maybe it is time to go back to the beginning, and ask ourselves,

“What is the problem we are trying to solve?”

If we did that, we could find better ways of solving these problems without the resulting dysfunction.

 

Injecting advanced questions

/by

One of the great problems with Scrum is that the ceremonies become repetitive. The ScrumMaster runs all meetings using the same agenda, and small omissions never get rectified. This means that even with the best intentions, after six months or a year, you may be routinely missing out on something.

For example, the daily standup can become a repetitive meeting where you just rehash the three basic questions. People think that the daily standup is just a reporting meeting, and forget the opportunities to improve flow and reduce risks.

Photo "Scrum standup seriousness" by vishpool

One way that an external coach can help is by injecting advanced questions. Coaches by definition are process experts, but can be excused for not having local domain knowledge. This means that it’s easy for us to ask those “stupid” questions that employees don’t feel inclined to ask.

In the daily standup, for example, a coach can ask questions like:

  • Are you going to make it this sprint?

  • Which story can you get done tomorrow?

  • Are you doing any work that is not in the sprint backlog?

  • What’s your major technical challenge just now? And next week?

  • Do you have here all the information you need to make good decisions?

  • Is somebody unhappy with the plan for today?

While you can of course draw up a pre-defined list of questions to inject, the best questions tend to arise from observations. Look at how the team is doing, try to understand where the team is lacking and come up with a question that highlights this problem. If possible, try to focus on items and events rather than people and decisions. It can also be good to state the observation that led to the question.

Pose the question immediately if it makes sense to do it. Otherwise jot it down and bring it up later, for example at the end of the meeting or in the retrospective.

Advanced questions like these help the team and the ScrumMaster get out of the rut and make better use of the ceremonies. Try it out in the next meeting — better ask and find problems than stay silent and not find them!

Photo “Scrum standup seriousness” by vishpool – http://flic.kr/p/7kFP2S

Talking about Agile Transformations at Keep Austin Agile 2015

/by

I am happy to present at Keep Austin Agile 2015 today, organized by Agile Austin. The title of my talk is “Measuring What Matters in Your Agile Transformation” and we will discuss together how can you clearly articulate the business goals of your agile transformation, and how can you effectively measure your progress and success.

We will show how to use the Agile Strategy Map™ to define your Agile transformation strategy, and give real-world examples of strategies used successfully by many organizations. Participants will get practice using the Strategy Map and identifying some metrics that matter.

Agile Strategy Map™

Before starting the journey to becoming an agile organization, it’s critical to define your business objectives: quality, time to market, productivity, customer satisfaction, innovation, employee engagement, or whatever challenges you need to address. To make those goals real, they need to be measurable. Because the journey may be long, you need both leading indicators to know if you’re going in the right direction, and lagging indicators to tell if your goals have been met.

The Agile Strategy Map is a comprehensive framework for guiding an Agile transformation, and the presentation includes many great examples of successful strategies used by many organizations. Participants will have the opportunity to develop a few parts of a strategy so their learning will ‘stick’, and they will also learn from other participants.

Workshop PMI Lean/Kanban Portfolio Management, Milano 9 maggio 2015

/by

Sabato prossimo sarò ospite del PMI® Northern Italy Chapter per un workshop dal titolo “Dialoghi con… Gaetano Mazzanti: Lean/Kanban Portfolio Management”. La giornata si svolgerà a Milano sabato 9 maggio 2015 presso il SIAM in via Santa Marta 18 dalle 9 alle 17:30.

Obiettivo del workshop è introdurre i partecipanti ai principi e alle pratiche Lean/Kanban e alla loro applicazione al Portfolio Management. Si vedrà come l’approccio Lean/Kanban consente di affrontare in modo trasparente i problemi del bilanciamento e della distribuzione del carico di lavoro, della selezione dei progetti e iniziative da avviare, della massimizzazione del valore generato ottenendo maggiore rapidità e qualità. Saranno inoltre illustrati strumenti quali Lean Project Canvas e tecniche alternative di stima, monitoraggio e previsione.

Maggiori dettagli sono disponibili nella brochure da scaricare. Purtroppo la sala è già al completo, per maggiori informazioni potete contattare il sito dell’associazione all’indirizzo www.pmi-nic.org, sezione Eventi.

Organizzeremo al più presto altri eventi a Milano, contattateci.

Get ready for Towel Day with agile42

/by

Towel Day is an annual celebration on the 25th of May, as a tribute to the late author Douglas Adams (1952-2001). On that day, fans around the universe proudly carry a towel in his honour.

“agile42 "Don't Panic" collectible towelThe Hitchhiker’s Guide to the Galaxy has a few things to say on the subject of towels. A towel, it says, is about the most massively useful thing an interstellar hitch hiker can have.”

 And since our company is named after a very important concept explained by Douglas Adams we cannot but participate to the celebrations in our own style: by producing Don’t Panic-stamped towel for our clients and friends!

Get your own towel today: buy from our online shop and have it delivered on your doorstep faster than with an Infinite Improbability Drive spaceship.

A great way to get ready for the 25th of May!