What are the most important interpersonal skills needed for working on an Agile team?

[Dear Readers, I've been having fun on Quora lately participating in community discussions, and reposting responses to my blog.  Enjoy!]

What are the most important interpersonal skills needed for working on an Agile team?


One of the reasons “Agile” has grown so quickly is because companies, especially in IT, were heaping processes and oversight onto knowledge workers so heavily that it caused a backlash. People were anxious to throw off that oppression, and the popularity of agile represented an opportunity to really change - for the first time.

Managers have been preaching about “empowerment” and “pushing decision making down” for decades, but the processes they have been mandating had the opposite affect.

When Agile started to become popular in the early 2000s, it was because people were hungry for an environment that focuses on people over processes, and part of that was an acknowledgment that certain behavioral characteristic were critical towards achieving a vision of empowerment, autonomy, and self-organization.

Some of those characteristics are:

• Trust people’s good intentions
• Every interaction is about learning
• Do what you have to do to please the customer
• Support your other team members and help them be successful
• Don’t manage people, collaborate with them
• Succeed in small increments
• Be willing to change everything you thought you knew when you learn

So, the interpersonal skills should align with the list above - be a trusting, supportive, and learning team members that doesn’t dig in and insist they know everything. You’ll be fine if you do that!

Jeff Dalton is author of Great Big Agile: An OS for Agile Leaders, and is a CMMI SCAMPI Lead Appraiser, AgileCxO Assessor, and Leadership Coach.

What is SSOT in Agile Software Development?

[Dear Readers, I've been having fun on Quora lately participating in community discussions, and reposting responses to my blog.  Enjoy!]

What is SSOT in Agile Software Development?

SSOT = Single Source of Truth. 

It’s not an Agile thing, it’s a data warehousing/DBMS concept that has been around for decades, although lately we’ve been seeing Agile practitioners referring to it as “agile.”  While the creation, maintenance, and operations of the SSOT could be performed in an agile way (and should be), SSOT was not borne Agile movement.

It’s simply the “trusted data source,” or the source data for an organization’s various databases that is subject to a sufficient level of scrutiny, process, and testing to ensure reliability.  In the SSOT, each data element can only be stored one time, eliminating redundancy and chance for errors.

Like good leadership, team cohesion, good customer relationships, and experimentation, it’s been around a lot longer than the Agile manifesto has been around.

Jeff Dalton is author of Great Big Agile: An OS for Agile Leaders, and is a CMMI SCAMPI Lead Appraiser, AgileCxO Assessor, and Leadership Coach.

Moving from Retrospectives to Continuous Improvement

[Readers - we've been writing about the new version of CMMI lately, but today I'm happy to introduce our first guest blogger in a while, Leon Tranter.  Leon is an agilist and blogger from Sydney, South New Wales.  You can follow him on Twitter at: @LeonTranterEU.  Welcome Leon! ]

Moving from Retrospectives to Continuous Improvement

Retrospectives are one of the core ceremonies in Scrum, and considered an
essential part of Agile software development. They are even called out specifically
in the Agile Manifesto: At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly.

This regular "pause and reflect" activity seems to connect the Lean Manufacturing
idea of Kaizen or Continuous Improvement to the short time-frame iterative nature of
Agile software development.

Many people conclude from this that by performing Retrospectives, a team is thereby
doing Continuous Improvement. However, I would argue that this is not the case,
and that Retrospectives are in some way a move away from the Lean concept of Kaizen.

The main problem with Sprint Retrospectives is that they are by their nature done
every sprint (which is usually a two week iteration). This means that issues that come up
during the sprint have to wait up to two weeks before they are brought up at a retrospective.
This can make it hard for people to accurately remember the details of the issues, since
they are now dislocated from that incident spatially and temporally.

This also means that problems can go uninvestigated or unresolved for one or two weeks
during a sprint, further eroding the team’s effectiveness. A once per sprint event is not
“continuous”, it is in fact discrete - the opposite of continuous!

The true spirit of Continuous Improvement, from Lean Manufacturing, is that
improvement is something that is the responsibility of everyone in the company - not just
software developers everybody, from accountants all the way to the CEO. It is also something
that happens all the time - continuously.

When a problem happens, or someone notices a tool or process that is inefficient or not fit f
or purpose, they must stop what they are doing and call attention to it. And the organisation
must treat this seriously and resolve to fix it, ideally then and there.

As an example, Toyota car factories have something called “Andon Cords”, which are
cables hung from the ceiling over an assembly line. If a worker notices a problem, they pull the
cord - the entire manufacturing line comes to a halt and those in the area huddle around to
investigate and resolve the issue.

This behaviour is a true reflection of the meaning of Continuous Improvement, an idea
some call “Stop and Fix It”. This requires a significant change in the mindset and
behaviour of the organisation, which is usually focused on day to day operations, and
deferring non-urgent problems for another day. Retrospectives were designed with good
intentions but fit too easily into this mold. Moving to a true Kaizen organisation is a larger
shift but with potentially huge payoffs for those that can make the transition.

Leon writes about Agile and Lean at his blog www.extremeuncertainty.com. Why don't you check it out right now?

Like this blog? Forward to your nearest engineering or software leader!

Jeff Dalton is Chief Evangelist at AgileCxO.org, and a Certified SCAMPI Lead Appraiser, Certified CMMI Instructor, author and consultant with years of real-world experience with the Agile and CMMI in all types of organizations. Jeff has taught thousands of students in Scrum Master, Product Owner, and CMMI training classes, and has received an aggregate satisfaction score of 4.97 out of 5 from his students.

Visit www.broadswordsolutions.com for more information about engineering strategy, performance innovation, software process improvement and running a successful Agile Transformation or CMMI program.