Adopting Agile Scrum (With caution) by Bogdan Suteu

Some time ago (November Last Year 2015) I’ve challenged a friend that is a Scrum Master (Bogdan Suteu) to write an article sharing some of his past experiences.

The result from the invitation was that he accepted the challenge and today I’m sharing his article as invited writer from this Blog.

It’s a really interesting article since we have some good points that we should keep in mind when we are helping a team or business during their transition to adopt Agile Scrum.

Having said this, please find the article below:

Nowadays, everyone uses the word “Agile”, “We are Agile”, almost to the exhaustion. But my question is… Do they know and understand what they are saying and what it means?

For that, I must explain you what is in my mind!

What makes any business powerful and competitive is their ability to constantly adapt to market change, while delivering quality products. Agile Software Delivery with its Scrum flavour give us the tools for having high performant teams with the availability to have a fast, high quality and perfomance delivery this way being able to achieve highest customers satisfaction.

Nevertheless, being transparent, adaptive, responsive to change and able to deliver at pace may be everyone’s dream, and yet a lot of teams and business are reluctant in adopting an Agile Scrum approach for Software Delivery.

As a result, I truly believe that ,we shouldn’t use Agile because is the new buzz word in the industry and because everyone is using it. We should use Agile Methodology in order to survive in this industry, but most of all be competitive and be ahead of the competition. Yes, that’s right. To survive in this wild, dynamic and competitive market/world. So, if you really want to succeed, you need to be able to get outside your comfort zone and take actions.

Agile is much more than having iterations, a definition of done, product backlog refinement meetings and so on. Agile means a cultural change at an organisational level, where people start to take ownership of their commitments and actions, and also, start to reflect on the way they think and work.

In the context of Agile Scrum adoption, there is no “smooth sailing” all the time. From my experience by working with scrum teams, I identified some anti-patterns that can make everyone transition/adoption more difficult.

1) One pitfall is to implement Agile for solving problems that don’t require Agile in order to be solved (Depicted below), on top of this, create performance metrics focused on data that is not accurate or reliable. Taking actions based on those metrics, will lead to a failed Agile transition/adoption.

Applying Agile Framworks

2) Trying to change every single issue that you’ve found really quickly, can lead to failure. Agile comes with a lot of benefits but also creates a lot of transparency, awareness and bad pattern revealing. Setting realistic actions and timeframe for implementing them will make people to be open and to get outside their comfort zone easier.

3) Agile Implementation & Support must come from top to bottom in an organisation. People need to be encouraged to share their lesson learned, and to feel that every mistake has the benefit of generating feedback &more powerful teams. Removing the “pointing finger/blaming culture” and trying to promote team spirit together with a culture of winning together / loosing together must first come from the top management. Do not be afraid of failing, but learn from your experience and each time, take actions.

4) Micromanagement days should be over! We should have small, but solid steps in creating self-organizing teams that can deliver valuable software each iteration. The management should create the safe environment and act as an enabler for those teams.

5) The term of a Cross functional team can be really misunderstood. Try to encourage “T shaped people” to step in. For example, one backend team member can change a label on a contact form. Encourage those types of inter-technology mix. Do not abuse of that from the very beginning, but make sure that you have willingness needed in the team.

6) First and foremost always try to keep delivering High Quality. Try to reach a sustainable pace while delivering high quality products. What’s not done, almost done or done but with “minor” defects (according to team’s definition of done) should be moved back into the project backlog. Try not to split established units of work or to create defects just to cover for “almost done” work. This is just enormous source of debate and politics. And it’s misleading for everybody.

7) Even if we implement everything with caution, with small solid steps, eventually Agile is not for everyone and we can expect that some people will not be on board. It demands an extra effort to leave comfort zone and maybe leaving your ego at the door.

8) Be flexible and patient. 😉 That’s so easy to say, but if you want to have most of the crew on board, you need from time to time to adjust and refine your agile processes. Change the retrospective format, cancel a product refinement meeting in a busy day, bring chocolate to the retrospectives, and be sincere and empathic.

So, is your organisation up to the challenge?

My feedback is that is really an interesting article showing his past experience and point of view. I hope that you enjoy reading it like I did.

The Scrum Year Retrospective by Nuno Gouveia

Today, is the last day of the year 2015 and there is nothing better than talk about Retrospectives. Having this said, this time I’m not writing one of my articles but instead I would like to share with you an article written by my friend Nuno Gouveia (Scrum Master from the Avengers Team).

After reading his article “The Scrum Year Retrospective” I thought that was really great to share with you their idea on how they could keep improving as well their experience regarding the Scrum Year Retrospective. Not forgetting the outcome results and feedback from this experience.

For me it’s really amazing when we see teams with this innovation spirit. In other words, not having afraid to fail and with continuous improvement as a team value.

Having said this, please find the article below:

Background
I’ve been acting as Scrum Master for my team (Avengers) for the past few months. Just to give some context, we are a team with some experience with Scrum and some of us have been working together for about 2 years now. Our retrospectives usually have a lot of good discussions and I like to believe that we are not the type of team that sweeps stuff under the rug. Our biggest problem is really that sometimes we discuss so much that we start deviating from the issues at hand. With that in mind, on my first retrospectives as a Scrum Master I tried not to change too much from what was the routine retrospective (+/- board with post-its) and focused instead on trying to not let the team scatter too much on the issues being discussed.

For the past 2 sprints I’ve been working with another team member that is also acting as Scrum Master, so we can say we are a kind of a Scrum Master’s team. The experience has been very good and last sprint, we had a great idea for a retrospective and this post is to share that experience.

The idea
The idea was to do a year review or year end retrospective. This seemed a great idea but there was a big problem: if sometimes in the sprint retrospective we have a hard time remembering everything that happened in the last 2 weeks, how would we remember all that has happened during one entire year? To solve that problem we had the idea to do a year timeline that could represent all the main events that had happened during that time. So a couple of hours before the retrospective we (the Scrum Master Team) tried to capture the most outstanding events from each sprint. We also decided to take screenshots from the most important product features we developed. We assembled the timeline on a big paper just a few minutes before the retrospective and then called everyone into the room (the result is the image in the cover of this post).

Year Retrospective

We started by explaining what was going to happen to the rest of the team. We told the team that besides our usual sprint retrospective we would also do a retrospective of the entire year. After that we unveiled the year timeline and everyone looked quite surprised! We went over the timeline together and while at it we decided (with the team’s input) to add the time of the year when the team new members joined in. After that we gave everyone around 10 minutes to write post-its for good and bad things that had happened during the last sprint or the entire year.

Results
There were a lot of post-its both from the last sprint and from the entire year and that generated a lot of discussion, and it was the first retrospective where the number of post-its for good things exceeded the bad ones! It was very good to revisit some old discussions and try to get closure in others. We have been improving as a team with each sprint retrospective, but this was a totally different experience that allowed us to step back and realise how far we had come since the beginning of the year.

Conclusion
In the end it was an amazing experience and we had a very good feedback from the team. If you haven’t done something similar yet I would recommend that you try this with your team, either to close this year or to start the new one!

Postits
Good 2016!

Nuno

My feedback from this is simple: Great article. I hope that you enjoy reading it like I did.

See more at: The Scrum Year Retrospective by Nuno Gouveia

 

Agile Maturity Self-Assessment Survey (Published at ScrumAlliance)

Sharing my recent article publish by Scrum Alliance today, Tuesday 8th of December 2015.

This article identifies questions you can use to create an Agile Maturity Self-Assessment Survey, and it discusses the importance of this type of survey.

You might be asking why you would need a survey. Well, I truly believe in constant feedback. There is no better way to challenge the status quo. Also, it helps us understand what we can improve, how to be faster, and how to be more adaptive and responsive to the changes or challenges that come our team’s and business’s way.

Keep in mind that these kinds of tools are what allow us to improve what we already do well and to help us gain a clear view of where we need to focus our efforts. To that end, I think that the best place to retrieve this feedback is from the people who deal with the real scenarios every day. They are the best at evaluating their team and business for Agile maturity so that they can identify the anti-patterns and develop possible solutions and corresponding actions for improvement.

For these reasons, some time ago I searched on the Web for existing surveys that I could use and was able to find one that, from my perspective, was complete and had all the right questions.

So, the next step was to create the survey and send it to everyone. The number of replies was very good, and some conclusions were interesting, but (there is always a but) the survey feedback included the following remarks:

  • It was too long.
  • Some questions were not clear enough to understand and answer.
  • Some of the questions were hard to answer because they didn’t have a full overview.
  • It was confusing if you did not have a Scrum role.

Again, after this feedback and based on my beliefs, I decided to collaborate with a few people who answered the survey and a few others who face these challenges every day. These collaborators have also decided to accept the challenge to become Agile Champions or Change Agents.

I was amazed by their motivation and commitment to help improve the survey and their commitment to understand its results. It was really impressive!

After long discussions and reviews, the result of this collaboration was the following improved survey:

Your Role

  • Dev Team Member
  • ScrumMaster (dedicated)
  • Product owner / Manager
  • Delivery Manager / Head of / Director
  • Project / Program Manager
  • Other

1. Which Agile framework does your team use?

  • Scrum
  • Kanban
  • Other
  • None

2. Is your team able to deliver valuable software frequently?

  • Never
  • Seldom
  • Sometimes
  • Often
  • Always

3. How often do you think that we are delivering what the business needs most?

  • Never
  • Seldom
  • Sometimes
  • Often
  • Always

4. Is your team accommodating all the changes suggested by the product owner?

  • Never
  • Seldom
  • Sometimes
  • Often
  • Always

5. How often does your team have visibility into what it will be doing in the next three sprints?

  • Never
  • Seldom
  • Sometimes
  • Often
  • Always

6. Does your team have an agreed and clear DoR (Definition of Ready)?

  • Yes
  • No

7. How often are the user stories that enter your sprint ready to be implemented?

  • Never
  • Seldom
  • Sometimes
  • Often
  • Always

8. How often is your team being disrupted and controlled by outsiders during the sprint?

  • Never
  • Seldom
  • Sometimes
  • Often
  • Always

9. Does your team find blockers during the sprint?

  • Yes
  • No

10. Are any blockers found being tackled in a timely manner?

  • Never
  • Seldom
  • Sometimes
  • Often
  • Always

11. Is your team collaborating daily? (Ex: Daily stand-up)

  • Never
  • Seldom
  • Sometimes
  • Often
  • Always

12. Is your team motivated to deliver the sprint deliverables?

  • Never
  • Seldom
  • Sometimes
  • Often
  • Always

13. Do the Scrum team members trust each other?

  • Never
  • Seldom
  • Sometimes
  • Often
  • Always

14. How often, when it’s possible, does your team communicate face to face?

  • Never
  • Seldom
  • Sometimes
  • Often
  • Always

15. Does your team have an agreed and clear DoD (Definition of Done)?

  • Yes
  • No

16. How often is your team able to deliver fully tested, working software at the end of the sprint?

  • Never
  • Seldom
  • Sometimes
  • Often
  • Always

17. How often is your team able to deliver at a sustainable pace?

  • Never
  • Seldom
  • Sometimes
  • Often
  • Always

18. Is your team striving for quality and technical excellence by Betfair standards?

  • Never
  • Seldom
  • Sometimes
  • Often
  • Always

19. Is your team self-organized in accordance with Agile principles?

  • Yes
  • No

20. Are the team members locked into their specific roles?

  • Never
  • Seldom
  • Sometimes
  • Often
  • Always

21. How often is your team able to reflect on whatever has happened? (Ex: Retrospective)

  • Never
  • Seldom
  • Sometimes
  • Often
  • Always

22. Does your team take appropriate actions based on whatever has come up in retrospectives?

  • Never
  • Seldom
  • Sometimes
  • Often
  • Always

23. Is your team continuously improving what it does (including processes)?

  • Never
  • Seldom
  • Sometimes
  • Often
  • Always

24. Is your team using performance metrics to improve team performance?

  • Never
  • Seldom
  • Sometimes
  • Often
  • Always

25. Do you have any ideas on what we could improve regarding our software development process?

  • (Open Question)

My thoughts are to continue to analyze the next feedback and review this survey periodically with all the Agile champions (each time with a small group to be able to stay focused).

Please let me know if you have any questions or if you want to share your own experience on this subject. I would like to hear your thoughts and opinions.

See more at: ScrumAlliance.org | Agile Maturity Self-Assessment Survey

When to take the decision? What decision? by Nick Maroudas

Today, I would like to share with you an article written by my friend Nick Maroudas.

After reading his article “When to take the decision? What decision?” I thought that was really great to share with you.

So, my next step was ask him if I could share the article in the blog and after a few seconds I got his answer as you can see “Accepted you can take it 😄”.

Having said this, I’m happy to share the article link:

When to take the decision? What decision? by Nick Maroudas.

Nick

My feedback from this is simple: Great article. I hope that you enjoy reading it like I did.

Lean Coffee Portugal Community!

After the Lean Coffee Porto and Braga continued success, today’s post is related with the most recent update that is Lean Coffee Portugal.

Logo Portugal

It’s really amazing to see this community growing month after month. Better than this, is the people’s motivation attending every month as well the new people joining our community.

The result from this is the 9th Edition in November @Startup Braga and the expectation to keep coming and growing!

I will be there and you? Are you joining us to share your knowledge and experience?

CAS 2015 Agile Spain :: TALK Why for Some Product Owners and Stakeholders Agile is Like Crossing Over to the Twilight Zone

Was with great pleasure that I found out last week 20th of Oct 2015 that:

“Yesterday we finished the selection of talks and workshops for the conference, and your proposal was selected. I’m talking about “Why for Some Product Owners and Stakeholders Agile is Like Crossing Over to the Twilight Zone”.

Congratulations!”

I’m really happy to be one of the speakers for this conference. Nevertheless, share and learn with everyone!

See you there 😉

Road Maps and Release Planning – The never-ending story (Published at ScrumAlliance)

Sharing my recent article publish by Scrum Alliance  on 6th of August 2015.

Again its a very interesting and hot topic called “Road Maps and Release Planning – The never-ending story“.

I hope that you like reading this article as much as I enjoyed writing.

Why for Some Product Owners and Stakeholders Agile Is Like Crossing Over to the Twilight Zone (Published at ScrumAlliance)

I’m happy to share with you that I have my first article approved and publish by Scrum Alliance  on 23rd of July 2015.

Its a very interesting topic called “Why for Some Product Owners and Stakeholders Agile Is Like Crossing Over to the Twilight Zone“.

I hope that you like reading this article like I enjoyed writing it.

Agile Champions the new Change Agents!

As promised in my previous post “Does the Change Agent Networks work? In my case the Agile Champions…” I said that I would share some conclusions about this model implementation.

During this time I didn’t said nothing because I needed some time to start seeing the first results. Well, good or bad…

As you know, transforming mentalities doesn’t work from night to day. In reality takes time and in some situations more time than expected.

Having this said, I would like to start by giving some context in case that you are reading this Blog/Post for the first time.

As an Agile Coach I’m responsible for providing guidance and support in agile concepts and principles to multiple teams distributed across 3 locations (Portugal, United Kingdom, and Romania) in the company that I’m currently working.

After working for a period of time with different environments and cultures, I’ve realised that some times it’s really hard to help people to change even when that change is beneficial to them, others and the business.

So, during one of the many conversations that I had, one person in particular asked why shouldn’t we try to motivate and empower people to be change agents? From that moment I started to plant this idea, like a seed, in everyone’s mind.

Now it’s the time to share some conclusions but please keep in mind that this is work in progress. In other words this is on-going work will never be complete.

The first step was do a roadshow by all locations with the objective to share what was an Agile Champions and what was expected from them. The first reaction was not what I was expecting. Meaning that, almost everyone was with the suspicious look. Also, because cause some confusion. They thought that was another role or more responsibilities added to their current role if they accepted.
From this moment, I had to keep working with them. Clarifying any existing doubt what was an Agile Champion “ An Agile Champions is some one that truly believes in Agile and the change. Believes what are the benefits that can come with the change and is ready to take actions to bring more people on board”. I can say that was a motivational and coaching continuous work.

After achieving this first step, some people started to attend the weekly meetings. During this meetings we discussed what could motivate people to become an Agile Champion, to attend the Agile Communities sessions (share and learn) and to have the will to take actions and bring more people on board. Agin, this was another critical moment. Lucky went well since I had people believing in Agile and committed to this, as well, the Leadership Team support. They were the key to keep this proceed to success even in a slow pace.

It’s funny because if I go back in time, the reality was that I only had one or two Agile Champions since the beginning. Was our work together that made more people to believe and have the will to join us.

At this moment in time we had a small group on each location but I still had the need to drive these meeting and communities. Everyone was expecting that even during this time I was saying that would be really great if they wanted to do it.

Luckily or not something happen accidentally. After a few months suddenly I had the need to start traveling more. Meaning that, I was unable to attend all the weekly meetings and community sessions on all locations. The surprise was that in a natural way they were more committed and self-organised than they and me were expecting.
They started to schedule the weekly meetings, discuss what they could do to keep improving, talk about ideas for the Agile Communities on each location, how to involve and bring more people on board.

For me this was a magical moment! The moment that the Agile Champions had become Change Agents! The moment that I truly believed that the viral change was going to work!

Please let me know if you have any question or share your own experience on this subject. I would like to ear your thoughts and opinions too.

Lean Coffee Braga Community!

After the Lean Coffee Porto continued success, today’s post is related with the Lean Coffee Braga.

logo-color-braga

This happened yesterday in the beautiful city of Braga at Primavera Software.

If you asked me some time ago “Did you believed that in a short period of time would exist the Lean Coffee Porto and 3 months later the Lean Coffee Braga would start”, I would say no. But I was wrong!

They are real, they are a big success!

Not just due to the Co-Founders but to everyone involved. That, after a day working day, they are still motivated to attend, share experiences and learn.

I’m a truly believer that together we can grow more and faster.

For more details please check the bellow links:

Many thanks to everyone for making this real!