This blog has moved. Go to SoftwareDevelopmentToday.com for the latest posts.

Friday, August 30, 2013

Most Awesome people to follow, the #ale13 version Part II


Yesterday
I posted about two people whom I think everyone interested in the topics of this blog should follow. I've met them at #ALE13 this year and am impressed with the work that they are doing. Today I'll recommend two other people to follow:
  • Kurt Haeusler: Kurt had a great presentation today on Offers and Pricing in Agile and Lean Software Development. The content of the presentation had many insights, but the one that stuck with me the most was his comment on how Lead Time (the time it takes to deliver something to a customer, starting from the moment they customer as asked for it) is affected by far more significant factors than what is typically calculated when estimating a size for a User Story. The basic argument is: there are many factors that affect delivery date that have nothing to do with the time it takes to develop and test the functionality. Therefore, Throughput and Lead Time are much more important metrics than what we may think something takes to code and test. To this already convincing argument, he added: "and random events within a system also affect Lead Time". A light bulb went on in my head: this is a clear argument for the #NoEstimates approach I advocate.
  • Jurgen Appelo: Jurgen has been active in the Agile community at least as long as I have, so you probably already know about him. But the work that he is presenting on Tribal Businesses has the potential to revolutionize our industry. The cool thing: he is implementing his ideas through the Happy Melly project, so you will be able to follow his progress directly. I'm also involved in the Happy Melly project.
Who will you start following from the #Ale13 crew? Share their twitter handle/blog URL and why!

at 18:23 | 0 comments
RSS link

Bookmark and Share

Thursday, August 29, 2013

Amazing content created by Agile practitioners can change lives

Have you heard of Scrum? An Agile methodology that swept the world by storm? Or Real Options? An approach that can change you manage risk and value in your projects? Or Impact Mapping? Probably the most revolutionary product management and requirements management approach created in the last 10 years?

You can change people's lives

I believe that many of the people attending agile conferences around the world have amazing content to share with the world. I have lately tried to help people get started expressing themselves by sharing what they have learned. And some have already done that. But how to help you?

I have been thinking about what are the obstacles that prevent us from taking the steps to start sharing what we have learned. Some of us are busy, maybe too many things started, maybe we dont feel comfortable with being "out there" and potentially being judged by people that we admire?

Honestly, I dont know. The reasons are different for everyone. What I do know is that I can help you by removing some of the obstacles that stand between you and your future audience. The people that will learn from you, from what you have learned,  from what you have achieved. 

My mind was blown today!

This became very obvious to me today when I was talking to Joe Justice of Wikispeed fame, I was so happy to meet him and to be able to tell, him that I had followed his work for a long time and admired his achievements.  But then he surprised me. He told me that he had learned something that he valued from my talk on #NoEstimates!  My mind was blown. Wow! I created something that somebody liked and that someone was an Agile idol of mine?

The thing is, many of you can do the same! By sharing your knowledge and helping people around you do the same you can change people's lives.

Happy Melly Express: A project to help you

The project that I am working on is

Happy Melly Express. The goal: to help you publish your work, and help your audience grow, touch real people in your community and (probably) change their lives.
Knowledge is a powerful life changer. Remember people believed (knew?) that he Earth was flat, or that waterfall was the right approach to develop software. That has forever changed thanks to people willing to share their stories,  their experience.  When will you do the same?

If you have an idea that can help get Happy Melly Express achieve its purpose share it with me. You can find me on twitter (@duarte_vasco) or via email (duarte_vasco at yahoo).

Labels: , , , ,

at 13:11 | 0 comments
RSS link

Bookmark and Share

Most awesome people to follow, the #ale13 version

Here are some of the awesome people that I have met at #ale13 and you should follow on twitter:

Need to run to the next session, I will let you know about more awesome people to follow soon.

at 11:37 | 0 comments
RSS link

Bookmark and Share

Friday, August 09, 2013

What is my role as a team leader? A continuous improvement guide to help you grow as an Agile Manager

What is the role of management? As an agile coach and as a line manager I’ve gotten or asked that question several times over the last 10 years.
When you introduce agile into an organization, middle managers (typically techs who climbed the management ladder) are faced with an identity crisis. I was also. I mean, if the teams are supposed to be self-organizing, supposed to solve their own problems, supposed to cross the “silo” and communicate with teams they need to cooperate with, what is a manager to do?
Annual performance reviews? I don’t know about you but I don’t see these are a useful use of my time. I’d rather be helping the teams excel, deliver great products! So, what is my role as a line manager for a team, or a few teams, in an R&D organization? What should I do every day to justify my office and high-salary? Or, if you are so inclined: what can you do that makes you feel the belonging that comes from achieving something together with your fellow human beings?

Managers have a different perspective

As a line manager I remember sometimes disagreeing with what the team was doing, I had a different perspective on the problem. But how can I bring that to their attention without affecting their sense of ownership and initiative? Intervening would make me happy, but affect the team’s sense of ownership and responsibility over their own work.
How to bring my perspective to their efforts to solve a particular technical, process or cooperation problem?
I decided to apply facilitation and I tried to have short conversations with teams only regarding the definition of the problem. A background analysis of current state as well as observed causality (a leads to b that leads to c, etc.) that led the team to face the problem they were struggling with.
What I learned by doing this was that I was right: often the teams did not have the full picture of the problem. But I also learned that I was wrong: during these conversations we would uncover observations and situations that we did not think about before having this conversation. It was a very important learning experience that would greatly influence my career in the future.

Managers have experience

During these short conversations we ended up discussing different perspectives on why the problem had surfaced and what the underlying causes were. Here I often gave my contribution, so that they benefited from my own experience in the company or in the particular domain.
At that time the team was dealing with technical problems I did not have enough experience in, but I did have a lot of experience with the organization where we worked, as well as with customer needs. My experience was useful to them. They would ask me questions regarding stakeholder expectations, customer needs and company politics. I would answer their questions and use my experience to ask other questions. I did not want to impose my views, but I wanted to challenge theirs, so that they could see beyond the surface of the problem they were facing.

Managers can help the team focus on the right things

Teams have the tendency to jump immediately into defining solutions, at this point I would ask them to try to focus on understanding better the problem and its root-causes. Instead of trying to solve every possible symptom or problem that they identified, I’d ask them to select one possible cause for the problem (identified through root-cause analysis) and tackle that.
Once they had selected a possible cause to address they typically would want to spring to action immediately, here I asked: “how will you know you’ve solved the problem?”. Very often teams want to spring to action without first creating an experiment that could validate their assumptions, they just assume they are right. I tried to be the skeptic in the process, asking them to state their assumptions and create ways to validate that they were right (metrics, experiments, etc.) or discover where their assumptions failed.
When they started implementing a particular solution, I followed what was going on and asked if they were still trying to solve the problem they’d identified before. When that was not the case, I asked: “why did you change? Have you listed your updated assumptions?” But I think that the most important contribution in these cases was to regularly ask them to define short-feedback cycles for their experiments. I challenged them to have something to check every day. The longer they went without feedback the more likely it was that they would fail to tackle the problem and know about it too late.

A new role for managers

Through this approach I defined a new identity for me as a manager. I shaped my role to be one of helping the teams take ownership and solve the problems they faced through the application of a simple problem-solving process. From there to being called an “agile coach” was just a question of the term becoming popular ;)

Help teams improve regularly

That is how I define my role today: someone who helps teams constantly improve. This is true for me, whether I am in the role of Agile Coach (which is my current role) or in a manager role. I help teams, and organizations walk the improvement path consciously and using a deliberate approach.
My experience is that teams can handle most day-to-day situations without my help. They can easily find who are the people and teams that they need to interact with. They can deliver software products on their own. But to deliberately improve they need coaching and support. This is not a lack on the part of the teams. In my view this is needed because teams are naturally driven by day-to-day events, and it takes them considerable energy and effort to deliberately focus on improvements in a way that delivers results and drives learning. Teams can solve problems on their own, we just need to help them do it deliberately and reflect on the knowledge they uncover during the process.

The process steps

Here are the steps I try to follow when working with teams on improvements:
  • 1. Background / current state: Observe what defines our current situation. Focus on observations, avoid judgments at this point. Just describe the situation.
  • 2. Consequences: What does the team or the organization need to do to keep the work flowing despite what you described in step 1? What work happens as a direct consequence of the current state?
  • 3. Dream state: What would the perfect world look like? Consider only the context of step 1.
  • 4. Benefits/Goals: How will your work be better once you have solved the problem? What steps will be removed or considerably reduced?
  • 5. Select root cause to tackle / Solution: What is the specific component of the problem that you want to tackle first? Think back to Consequences, Dream state and Benefits. Pick one benefit you seek, walk the causality chain back to determine root-causes and select one of those root-causes to tackle.
  • 6. Action points and follow-up: Now that the team knows what root-cause to tackle, how will they do it? Help them be very specific by listing concrete actions and having team members pick which they want to be responsible for. In this step try to help the whole team speak. Remind them that an important action point is to collect the necessary data to evaluate the effectiveness of the solution they picked.
Once the action points are defined don’t let the team forget about them. The team can (and will) change those actions, but they should review them and reflect on what they have learned.
The goal of this process is to help the team jump out of the day-to-day buzz of work and focus on problem solving, even if only temporarily.

Try it out and let me know how it worked for you. Photo credit: Drachmann @ flickr

at 16:57 | 1 comments
RSS link

Bookmark and Share

 
(c) All rights reserved