agile42 Insights: What Are the Attributes of a Great Agile Team?

/by

Every team is different, but we can identify some important, common features: a great Agile team is cross-functional and often small, dedicated, with a shared goal and vision. It’s also usually colocated, working in the same room together to achieve the maximum communication bandwidth. Collaboration, respect, trust are the key words often mentioned.

Watch the opinion of coaches Jan Beaver, Dave Sharrock, Brad Swanson and Richard Dolman in this 2-part video.

Part 1:

Part 2:

Code Dojo Python a PyCon 2014

/by

Il Code Dojo e’ rivolto ad un pubblico di programmatori Python che vogliono provare la pratica del Test Driven Development. Lo svolgimento degli esercizi è preceduto da una breve introduzione teorica ed una dimostrazione pratica, così che anche i neofiti del TDD possono partecipare (è comunque richiesto si saper programmare in Python).

Cos’e’ un Code Dojo? Nelle arti marziali giapponesi il Dojo è “il luogo ove si svolgono gli allenamenti alle arti marziali”. Un Code Dojo è il luogo dove ci si esercita nelle pratiche di programmazione. Questo, similmente alle arti marziali, viene fatto imitando i praticanti più esperti, confrontandosi e condividendo l’esperienze con gli altri programmatori.

Maggiori informazioni sul sito di PyCon Cinque.

man sitting in the top of the mountain

Certainty

/by

I read an amazing post the other day on certainty, and what happens when we are certain of things.

 

You can read the post here – The Dangers of Certainty: A Lesson From Auschwitz

 

Personally I found it valuable and interesting. My main take away was about the dangers of certainty. To quote the author:

 

“When we think we have certainty, when we aspire to the knowledge of the gods, then Auschwitz can happen and can repeat itself. Arguably, it has repeated itself in the genocidal certainties of past decades.”

 

This lead me to thinking about certainty in software projects and software teams. How often have I heard people who are certain, that theirs is the only way to solve a particular problem.

We have to do it this way… Or
This solution is the only way… Or
This product is the only one… and so on.

How often in software projects are we certain about the way forward or the tool that will be the solution to all our problems? How often are we wrong about that?

 

Certainty kills possibility

 

When we are certain that we have the best solution to a problem, then we don’t explore different ways to solve the problem. When we are sure about the right way to create something we don’t explore other possibilities. When we are certain that our way of doing something is the only way, we are less likely to collaborate with others, especially if they do not agree with us.

 

Certainty kills innovation

 

When we are certain that there is only one way to build something we lose innovation. If we are certain we are less likely to open ourselves up and less likely to try something different, or be innovative. When we are challenged and constrained, then we are far more likely to think of different and innovative solutions. When we are certain we are less likely to challenge ourselves.  Sometimes its even worth creating constraints that don’t exist to shift your thinking onto a different level and enable more creative thinking. If you are certain, you don’t explore constraints and you don’t challenge yourself or your solutions.

 

Certainty kills motivation

 

When someone else is always giving the answers to problems, people are far less likely to try and solve the problems themselves. When someone shoots down ideas because they are certain that their ideas are better, people are less likely to volunteer information. All of these behaviours will contribute to a lack of motivation from people. People want the chance to be heard and to have their ideas tested and taken in to account. Certainty on the part of another team member, or even more a person with positional authority like a manager, means that often that team member is not open to hearing the ideas of others or taking them in to account. 

 

Certainty doesn’t help in our decision making or problem solving, as much as taking solutions out of a box and applying them to your situation doesn’t work. Whatever problem you are trying to solve and whichever method you use in in solving that problem, questioning will take you much further than being certain. Being a little uncertain will help you to ask questions around what you are worried about, and will help you to understand what you are missing. 

 

To keep questioning the status quo and to keep asking if you are doing things the best way for you and your team is very valuable. A solution that is certain for today, may not be right for tomorrow and so to be certain of anything feels a little like blindly following a process, person or idea. 

 

Maybe if your team mate had been less certain about the right database to use you would have suggested another alternative.If your manager had been less certain about the right way to go forward with this project someone would have suggested a different alternative. I often find questioning the status quo and questioning especially when I am feeling certain, can lead me in a direction that is better than the direction I was going in to begin with. 

agile42 present at Global SCRUM GATHERING® New Orleans 2014

/by

Richard will be on stage with Steve Spearman to present Smart Scaling: Finding the right approach for Enterprise Agile focusing on whether we find to ways to deliver value without need to scale too big.

Brad will facilitate two workshops together with David Haws, the first one Getting Your Agile Team from Good to Great in which participants will collaborate to identify the characteristics of a great Agile team, the biggest challenges they’ve encountered, and identify specific solutions, the second Lean Startup + Story Mapping = Awesome Products Faster during which a team will start with a partially completed Lean Canvas to flesh out and then define a roadmap by building a User Story Map for the product.

And don’t forget that Call for Papers and Registration are open for Global SCRUM GATHERING® Berlin 2014 in September!

Talking about Agile Compliance at IBM Innovate

/by

Agile software development is a light framework that focusses more on early value delivery and incremental improvement than traditional tasks like detailed up-front planning, comprehensive specifications and technical documentation. But from the perspective of regulatory compliance, this planning and documentation serve a purpose.

How can we reconcile agile approaches that value a working product over documentation with the need to meet regulatory requirements for, e.g. medical devices or telecommunications? I will discuss how to bring together the apparently conflicting needs of regulatory compliance and agile, and show by example how agile teams actually approach tough regulatory requirements in finance, healthcare and telecommunications.

Learning Objectives

  • How to use agile in a highly-regulated environment
  • How to incorporate strict regulatory requirements within an agile development approach
  • The power of agile as a risk-limiting software development approach

Here my slides of the presentation.

Photo “Read the Fine Print” by Phil Roeder – http://flic.kr/p/dp2VyM

My understanding of effective Agile Coaching

/by

Since years I work as external Agile Coach. From the beginning I searched for a good definition on what is agile coaching and was never satisfied on what I found. In this blog post I want to describe my understanding of our way of agile coaching and what is makes essential for our success at our client.

So many people call themselves agile coaches. My impression is that the impression on what agile coaching is is quite divergent.

One definition of coaching: “Coaching is unlocking a person’s potential to maximize their own performance. It is helping people to learn rather than teach them.” (by John Whitmore)

Some people say about a person, that the full solution lies already in the client itself and we just have to unlock it in our coaching. Others go more in a direction of a consult the expert, who knows the solution and should prescribe the solution on the new way of working. And again others just see agile coaches as another name for Scrum Masters. See also the comments by Sigi Kaltenecker & Bent Myllerup on Agile & Systemic Coaching.

From my experience both viewpoints doesn’t fit to the way I do my job.

Coaching – just have to unlock the solution in the client and the sense of urgency

Most people don’t do such a deep change on becoming agile just for fun. There is a sense of urgency that drives the need to change. Just coming from a coaching perspective on step by step discovering the solution takes too long for them.

Clients expect from me as the expert to help them to get faster to the benefits they hope to achieve. Often their even hope to get the solution, that they expect from an external expert/consultant. I can use parts of coaching approaches like systemic coaching, but at least I didn’t saw it suitable to stick purely to this perspective.

Consulting – Prescribing the one solution and the risk by the unknown context and long term sustainability

Major part of my work is to help organisations or teams in a limited time. With teams I just work in a few weeks to get them started. This creates a pressure to get to quick results, but going to the client and defining the one solution sounds unsustainable, risky and disrespectful.

  • Disrespectful – By my few days there I can’t never know the things the client knows about his environment with their people, products, systems and customers. I find I disrespectful, that I know on how their solution looks like. Their are so many variables and they know so much more about their environment.
  • Risky – By this lack of context it is likely to miss the point and make wrong/stupid suggestions, that could cause a lot of damage.
  • Unsustainable – It should be their system, that with their help will emerge over time. Their environment will change and they need to be ready to adapt their system to their needs. Just placing their my solutions brings risks, that they would stick to the system blindly based on my initial suggestions or
    that they are incapable on developing it on in a meaningful way. 

First I thought the problem on just sticking on how your agile solution should look like is a problem just of Scrum Masters becoming Agile Coaches, that try to bring in the solutions from the one or two environments they know.

Looking for the one and only simple solution is far more spread. Customers expect it – because they are unaware of the consequences and Agile coaches do it – because it is so damn hard to help a customer in a focused way without giving him THE SOLUTION.

My understanding of Agile Coaching

I think agile coaching is a balance between the described points.
It’s guiding without prescribing. We don’t start from a blank page and we use our experience to accelerate their discovery process of their solution.

Effective agile coaching is the process of supporting the client to improve by becoming Agile.

My measure of success is that the client raised his skills to improve, not so much the things happened through our influence at our presence more that it never stops. I’m much more happy on the changes/improvements happening without our influence afterwards. For me this is a key motivator and driver, which I tried to summarise in the blog post I do my job for the email I get half a year later.

The true challenge is to help to client in an fast and effective way without taking unsustainable shortcuts by dropping THE ONE SOLUTION.

We experienced a focus on teaching, mentoring, advising and coaching in the right moments as best to help to client in an effective and sustainable way.

  • coaching – the solution lies in them, support them to unlock it
  • teaching – delivering the needed concepts/knowledge (to enable the client to work in one of the the other states)
  • mentoring – role-modelling or pairing/partnering with the client to close the gap to get started
  • advising – by requested for solutions, give options or advises to be finalised to keep the clients ownership high

Consulting in the meaning described above is from time to time expected or suiting best to the situation, but it doesn’t bring us closer to our previous described goal of raising the clients capabilities of self-improvement.

What is suitable depends highly on the context and situation. In my experienced too many wanna be Agile Coaches have the tendency to focus too much on teaching and consulting towards the one solution. From my experience this is counterproductive, because the client doesn’t increase his capabilities to improve on his own.

My preference is coaching or using the other forms of interaction to enable the client for it later on. While you coach the ownership is fully on the client. I think this choice isn’t a matter of the personal style, it’s a matter of sustainability.

This is my understanding of effective Agile Coaching. Would be interested in your opinions, if it fits. Looking forward to your comments.

illustration by the author

agile42 invites you to Lean Kanban Southern Europe 2014

/by

We are happy to welcome the Lean Kanban global conference series to Italy! The Lean Kanban Southern Europe conference brings together professionals who realize the value of Lean thinking. This is the event for technology managers, business leaders, and change agents who want to build quality, predictable delivery, and a culture of continuous improvement into their organizations.

Part of the Lean Kanban global conference series, it’s been scheduled on a one-day format that will accommodate networking and participation from a diverse set of attendees.

The program is under development but already includes David J Anderson, Bjarte Bogsnes, Jabe Bloom, Joakim Sundén and many other speakers. This will also include the Lightning Talk presenters that are replying to our ongoing Call for Participation. Join us to share your experience on stage!

Looking forward to seeing you in Bologna on May 30!

MHA2014 Sponsorship and Speakers

/by

MHA2014 is Friday April 18th in Denver, CO.  This is the 4th year of this premier agile event attracting top speakers and practitioners from around the world. 

Brad Swanson will deliver 2 very interesting sessions this year that are sure to be crowd pleasers:    

Kanban Pizza Game: Maximize Profit by Managing Flow 

The Kanban Pizza game was developed and refined by agile42 coaches and has been played by dozens of groups at conferences around the world.  It is a hands-on simulation designed to teach the core elements of a Kanban system—visualize the workflow, limit your work-in-process (WIP), manage flow, make process policies explicit, and improve collaboratively.  It’s very fun and highly memorable way to learn and experience kanban and the power of limiting work-in-process. 

Real-World Success with Kotter’s Change Model

What does it take to sustainably transform a large enterprise into an Agile organization?  

Brad will walk participants through a real-world success story, using John Kotter’s eight-step model for leading large change initiatives. He will describe Kotter’s change model and explain how a 2000-person organization at Ericsson implemented each of the eight steps to make a dramatic and sustainable transformation into a highly successful Agile enterprise.

Richard Dolman will be co-presenting, along with fellow Denver-based Agile Coach Steve Spearman, on a new and exciting initiative – the Agile Scaling KnowledgebaseTM: 

Smart Scaling: Finding the right approach for your organization.

This session is among the first, highly anticipated, public presentations of an analysis model that’s intended to help you answer the question:

What is the right scaling approach for our organization?

This is obviously a very hot topic in our industry now but we haven’t seen much in the way of attempts to synthesize and present information on the various approaches in a fair and positive way. This session engages audience members by providing a broad interactive conversation around the facts and myths of scaling approaches and will help to evolve a newly created resource for unbiased information on scaling.  Participants will explore the major scaling options together, to better understand some of the key differentiators and criteria for choosing an approach. 

 After a quick overview of the major scaling frameworks, we’ll present the concept of the Agile Scaling KnowledgebaseTM (ASK) – an evolving tool for evaluating and selecting the right approach(es) for your organization.   

Stop by our booth to take part in a fun video contest, where we ask attendees for their take on “What is Agile?”, as well as other thought provoking topics.  See how a few of our coaches answer this question –