Please don’t call it Agile

April 27, 2015 Leave a comment

Please don’t call it “Agile”! Really!

I can’t stand anymore listening to the word “Agile” and seeing the main principles neither understood nor respected.
I can’t stand anymore seeing agile transformations where the only goal is the transformation itself as a new process to put in place.
I can’t stand anymore arguing with people who think to have understood “Agile” because they use some sticky notes and do some daily meetings.

For many people who do agile or want to do agile, the agile manifesto is often a piece of paper without real meaning.

I don’t have the agile manifesto attached in my room and the point here it’s not to be a “purist” of all agile principles. I don’t care. I do care about people: respecting people, giving people autonomy, motivating people, trusting people, collaborating and improving with people. I care about the human side of business: business done by people who wants to satisfy and delight customers, business done by people as it is their own private business. I always considered Agile as an enabler for all of this, as opposite of other ways to developing software where people are like “cogs in the machinery“.  Agile is “people oriented”. This is the most important thing to understand.

Agile for me is tightly linked to new Management principles and practices (ex: Management 3.0) and to the organisational structure and values. I believe that you cannot have Agile without changing or adapting the others points, unless they are already “people oriented”. I believe in “Guiding Structure“: the structure of your environment is the largest determinant of your behaviour. So if you want to have Agile ensure that all your guiding structures are “people oriented” too (management, organizational structure, values, rewards, etc.).

Advertisement

Filed under Agile Tagged with , , , ,

How I prioritized the criteria to buy an apartment

April 21, 2015 2 Comments

“You need to choose because you cannot have everything for that price.”

This remembered me the typical discussions I had with our Product Owner when I was working in a Scrum team. “Prioritization” was the answer. The Product Owner was used to discuss with us the requirements, giving priorities to maximize the return on investment. This time I’m not working in a Scrum team, this time the context is different and it’s me playing the Product Owner role.

Here’s the situation: I’m looking to buy a new apartment. “You need to choose among your criteria because you cannot have everything for that price” is what the real-estate agent said.

Now I start to better understand my old Product Owner… how can I accept to buy an apartment that doesn’t match all my criteria? And which requirements can I eventually leave out? Like a “contrappasso” punishment it’s now me the one who needs to prioritize because most likely I will not find an apartment matching all my criteria. The main question is: which are the most important criteria I need to match?

Start with MoSCoW technique

I started creating an excel file to list all my criteria. I grouped them by theme (building, cost, plan, etc.) and I used the MoSCoW technique to have a first prioritization. I soon discovered I committed what I call the first Product Owner sin: everything is a MUST. It’s not easy to tell that something is not a MUST when you think you need everything… So the real question is: what is a real a MUST-have? Which requirements can I leave out? How much one requirement is more important than the other?

I started to turn the questions. Instead of asking myself “Do you need a parking?” I asked: “Will I buy the apartment without a parking?” “Will I buy the apartment without a balcony?” I realized it’s easier to give priorities considering how bad it is if a requirement is not matched.. I progressed with MOSCOW prioritization but I wasn’t fully satisfied yet.

I don’t need Financial Prioritization

In software development we can prioritize different features by business value: the financial value of the feature, the cost of developing that feature, the risk removed by developing it, the knowledge created, etc.

If I was looking for an apartments with the goal of investing my money I could use financial prioritization, but for me it’s important to find a good apartment where I want to live. I don’t want to consider the financial aspects now (ex: buy vs. rental, the internal rate of return, payback period, etc). I decided to do not use any financial prioritization. By the way I would be interested to know if some Product Owners out there really use it in software development, because I’ve never seen a PO doing it (unfortunately).

Use Kano Model on desirability

What I was missing is something to help me understand how the criteria influence my overall satisfaction when buying the apartment. Then I remembered the Kano Model that is based on the fact that customer satisfaction (my satisfaction in this case) is not influenced in the same way by all features. Some of them are in a linear correlation with satisfaction, others are able to provide great satisfaction but are not fundamentals and finally there are features that if missing would make me feel unsatisfied.

Following this model the features are grouped in three main categories:

Must-haves: all the mandatory criteria of my new apartment. Without these I will be not satisfied of my new apartment.
The more, the better: all the features for which my satisfaction is correlated linearly.
Exciting to have: all the criteria that can provide great satisfaction but for whose absence will not decrease my satisfaction below neutral.

The idea is to ask for each requirement a functional (positive) and dysfunctional (negative) question assigning a predefined type of answer. The functional question is to determine how do you feel if the requirement can be met. The dysfunctional question is to determine how do you feel if the requirement can’t be met. The answers together give a category for the importance of the requirement.

I added in my excel file a functional and dysfunctional question for each of my requirement and I gave an answer to these questions.

Example of questions and answers:

KanoCriteria Apartement

The functional and dysfunctional answers match a category following the map below:

Kano MappingA – Attractive
M– Must be
O – One dimensional
I – Indifferent
R – Reverse
Q – Questionable (reflecting unclear results which cannot be graded).

At the end of the exercise I visualized my criteria on a Kano chart. Here below a simplified version of it.

KanoChart

I found the exercise really useful to visualize what is important and to see how the apartment criteria are related to my satisfaction. I will give it to my real-estate agent hoping it will help to find my new apartment.

What do you think ? Did you buy an appartement ? How did you prioritize among your criteria ?

Filed under Agile Tagged with , , ,

We should save Scrum from Scrum

November 17, 2014 3 Comments

It seems a paradox but it isn’t. I start to think that we should save Scrum from Scrum: from the weight of his popularity that could transform it in something different.

More and more often I see Scrum not well understood and applied in organizations. This concerns different aspects: Scrum roles, collaboration of people, estimation, etc. We have already a name for such situations: it’s the well known “ScrumBut”. The real problem is when the “But” part is much more bigger than the “Scrum” part and what is kept it’s just an iterative framework with people playing the Scrum roles and doing some ceremonies with the fundamental agile principles negatively impacted or no more present. You can see development managers playing the Product Owner role instead of someone with business knowledge, ScrumMaster with a subordinate hierarchical link with the PO, Scrum Masters who assign the tasks to people, estimation done by the team with in reality a Gantt Chart already done to tell how things should go… I’m sure you have already seen such situations and many others.

I think it’s time for reflection to understand where “Scrum” is no more “Scrum” and when it’s not bringing anymore the benefits it was developed for and why we have such common situations. Read more of this post

Filed under Scrum Tagged with , , ,

Agile misconception – fixed scope and fixed deadline

July 28, 2014 Leave a comment

agileMisconception

Filed under Agile Tagged with , ,

Impediments to agile

December 10, 2013 3 Comments

Just reading an article on things that impede agile… I share two points here (extracted from the original article):

  • Technical Practices

” …you cannot scale agile on crappy code, without collective code ownership and continuous integration – period, no debate!”

  • PMO

“The mother-ship of all agile impediments – actually not my quote!

A bit harsh? Well it depends.

A PMO that is steeped in governance that adds no value then absolutely! Gated controls are great provided they add value – have the requirements been signed by the Business, has the design been signed by the CTO, have you produced your weekly report, have you correctly RAG your Risks and issues. Mother-ship!

But a PMO that has made both the cultural and mindset shift to agile can be a huge enabler.”

Filed under Transformation to Agile Tagged with , , , ,

People is more important than everything

October 17, 2013 Leave a comment

I’m more and more convinced about this: “people is more important than everything”. For many years in the software industry we tought to have found the good method for successfull software development, always searching for processes, practices, framework… but did these practices and methods provide the expected results? Today the risk is that agile will be another of such methods that didn’t bring the expected results if we don’t understand what “agile” is.

I see a situation in which many people wants to use “agile” and start to do it, but what I see in reality is the fall of agile: “fragile”, “wagile”, “srum-buts”… so the question is:  what “agile” really means?
My passion for agile comes from the idea that the interactions between people are more important than processes, that people are the key factor in the software success. Attendind people’s need and the close collaboration among people can bring back the enjoyment to developing successful software. The agile manifesto defines what agile is, we can find in it the same idea:

“indivuals and interactions between process and tools”
“customer collaboration over contract negotiation”
“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.“
“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.“

Agile is not doing it but “being agile”… for that we should start focusing more on people.

Filed under Transformation to Agile Tagged with , ,

Scrum Gathering Paris – “Shu Ha Ri” and Spiral Dynamics

September 23, 2013 Leave a comment

The first day of the Scrum Gathering in Paris is finished. It has been really a great day. The sessions I have attended were mostly about the same theme: “Expanding an Agile Culture in a Complex World”. This theme aims to define cultural tools (patterns, management practices, methods, etc) helping to install in a sustainable way an Agile culture within organizations. Below the sessions I liked most and my main takeaways:

“Cuture > Process” – Henrik Kniberg
The opeining keynote from Henrik Kniberg showed what “agile culture” really means and how this is achieved in Spotify the company where he actually works.
My Takeaways:
Shu-ha-ri  (Follow the rules, adapt the rules, Ignore the rules)
“People > *”  (People are more important than everything else)

Agile à la mode? The long-Term Viability of an Agile Culture in France – Petra Skapa and Mack Adams
This session showed how it’s difficult to have an agile culture in French organizations: the French values are not in lines with the agile ones.
My Takeaway:
The transformation to agile in France is more difficult than in other Countries. Agile is a mindset and it’s adoption and success is directly influenced by the Country’s culture.

Changing Cultural DNA with Spiral dynamics to become thouroughly Agile – Dajo Breddels
Interesting session on how the humans interact and behave according to the spiral dynamics theory and how this theory can help on the cultural change needed for agile transformation.
My takeaway:
Spiral Dynamics theory can be helpful for the agile cultural shift.

Filed under Transformation to Agile Tagged with , , , , ,

Transformation to Agile is not easy

August 20, 2013 1 Comment

I had the opportunity to meet Peter Measey as trainer of my Certified Scrum Product Owner course and since then I started to read his blog. Some time ago I read an article about how the transformation to agile can be difficult and he made me think about it. I know that the transformation to agile is not easy for large organizations that worked many years with a waterfall methodology. It requires time and it requires a change in all the level of the organization and after all these changes it can happen that the organization is still far to be really agile.  One important aspect of the transition is overcoming the individual resistance and it’s not easy because human being are involved. From Peter Measey’s blog:

“If you think that transforming an IT system from one technical platform to another is challenging, try doing a technical transformation where the platforms have a mind of their own and may not want to change, or even have the ability to change!”

Working in a large organization that wants to go towards agile and knowing that the transformation is complex I always had one question in my mind:

Can a large organization, alone, be successful in the transformation to agile?

When I say “alone” I mean without asking for help from external agile transformation experts.
Maybe the transformation is possible but more painful and longer because you cannot rely on lessons learned or common patterns among different organizations or maybe it will end, as Peter says, to what is known as “FRAgile” or “WAgile” where organizations are not really agile even if they think to be. I don’t have my personal answer to this question right now… In the meanwhile I’m still thinking on Peter’s questions:

“Would you try to write a software system without employing expert software developers ? So why would you think that something much harder (such as transforming an organisation of human beings) can be done by people who don’t understand transformation? ”

Filed under Transformation to Agile Tagged with , , ,

Change your Organization: it’s about trust.

May 2, 2013 Leave a comment

Some days ago a colleague suggested me an interesting blog of James Shore about changing the organization. How an organization can become more agile? How an organization can improve their processes?
Successful organizational changes cannot be fully top-down or bottom-up, but is there really a difference between the two? James Shore thinks they are essentially the same thing: “Both are extremely difficult. Both require that people want to change.” So how can you introduce new ideas and help the change to happen? The central point is trust. James says “It’s as simple as that. When people trust me, I’ve been successful. It hasn’t even been hard. And when people don’t trust me, no amount of cajoling, persuading, beating with sticks, etc., will make a difference.” The way to change something in the organization is no-change. The approach is more to show people ideas, seeing what they think, talking about alternatives, listening to experiences, etc.

“#1: the Way to Change is No-Change. I’ve seen how hard organizational change can be, and so I no longer attempt it. I just share ideas, lead by example, and have fun doing it. If things change, great! It’s a much easier approach to life… and you know what? I think it’s made me more effective as a consultant, and as a change agent, too.”

I like this thought and I think James is right: at the end change is about trust and respect to earn this trust.

“We must be the change we wish to see.” – Ghandi.

Filed under Transformation to Agile Tagged with , ,

Rotating the ScrumMaster Role. I let the team decide.

March 26, 2013 2 Comments

Recently I have been asked by some stakeholders why it is always me in the role of ScrumMaster instead of just rotating it periodically inside the team. The motivations following this remark have been:

– It is recommended by agile.
– It has been done by another Scrum team inside the company and it worked well.

Is it really true that the SM role should rotate inside a team?

I don’t agree with the idea of having a permanent rule to rotate the SM role specially when it comes from outside the team and those motivations seemed to me not really valid ones. I also clearly remembered what is written in “Succeding with Agile” by Mike Cohn about rotating the SM role. What he says is that the habit of rotating the job of SM is not recommended and it could be done in some occasions and for specific reasons but not as a permanent practice. The risk to rotate systematically the role is that the stakeholders don’t really understand the duties of the ScrumMaster and they can start thinking that everybody can do it. We know instead that to be a good ScrumMaster we need particular skills.

Furthermore in companies that haven’t fully transitioned to agile and are mainly organized in a different way (ex: waterfall development) I find that there isn’t always a clear understanding of what a ScrumMaster really is. In such organizations the role of ScrumMaster can be a little different from team to team and it can depend on the context. Sometimes when these companies need a ScrumMaster they need also other skills and other responsibilities and in this case I think rotating the role is even more complicated and risky.

Why it worked well for one team inside the company? Why the rotation cannot be applied on every team?

The asnwer is simple: every team is different. It’s a mistake to think that what worked well for one team should work well for another and in my particular case between the two teams there were some differences: one team was a cross-functional team with no project manager and working on different functionalities of the application (from UI to DB),  the second team was a UI team working in a dedicated UI project with a project manager be also part of the team. The context was different and the role of the ScrumMaster in the two team was a little different too. As we told earlier, the context is important.

I didn’t think the motivations were really valid and I didn’t think it was a good idea too to put in place a permanent rotation. I clearly expressed my position to stakeholders but I didn’t want to defend this position alone… I was there to represent the team, I was the servant leader for the team so what the team thought about this? Did they feel the need of this rotation of SM role?

What I did as ScrumMaster

I decided to schedule a retrospective meeting with the team, dedicated to the subject of rotating the SM role, to know what the team thought about it and what they wanted to do.
The results of the Retrospective have been that the team didn’t feel the need to rotate the ScrumMaster role and they didn’t want to have a predefined rule to rotate it.  It should have been a team choice when someone in the team wanted to try the ScrumMaster role. One team member told in the retrospective that he would have been interested to try the role temporarly in view of taking then a CSM certification, but not immediatly. The team agreed also to put in place something to improve the situation when the ScrumMaster wasn’t available (back-up).

As a result of the retrospective we added  in the team wiki a section dedicated to the role of the ScrumMaster with all the responsibilities and the tasks to do.  This guide is actually used as a reference for the back-up ScrumMaster and to give also visibility outside the team on the duties of the role.

What I learnt

As ScrumMaster I tried to express my position to stakeholders giving the reasons why the habit of rotating the role wasn’t really a good idea but sometimes is not easy to convince people. In these situations you can do a step back remembering that as ScrumMaster you are a servant leader for the team and you can let the team decide. It’s much more easier if all the team agrees on a position to defend and legitimate it.

Filed under Scrum Tagged with , ,

← Older posts

%d bloggers like this: