Matt Badgley

My career journey has had me wearing many hats ranging from Systems Analyst to Programmer to IT Manager to Programmer to Director. Today, I work as a coach and instructor to the leadership and team members of organizations on their agility journey. I'm constantly practicing to be a good learner, aspiring to be an inspiring leader, and I'm constantly walking the line between pragmatism and conviction when it comes to the application of lean and agile principles and practices.

Matt’s purpose is simple, “I believe in working with teams to help them get better, learn, and be successful in building stuff while having fun.”

At the end of the day, Matt believes in integrity, hard work, curiosity, people, and faith.

Five Ways to Establish Trust


As everyone knows, a key success factor of an agile process implementation, specifically Scrum, is establishing trust between the team delivering and those waiting on the delivery (basically between the product development team and the business).  In order to establish trust, a development team should be meeting their commitments made during the planning meetings; thus, delivering what they said they would.  Sounds like a pretty simple formula and for the most part — it is.

Never trust the teller. Trust the tale.
– DH Lawrence

Outside of simply delivering what you said you would in a sprint, here are five ideas to establish trust:

  1. Always act with integrity. It goes without saying, truth sets you free.  But what is more than simply being honest while communicating with someone, but it is more important to perform your job duties with integrity.  This means, no cutting corners, maintain the utmost quality, and always keeping the team informed when it comes to matters that may impact the core deliveries.
  2. Ask questions and share information. Make sure that if an idea is not understood, be sure to not be afraid to ask a question (sometimes, the first thing that comes out the mouth is “I don’t know”). Be sure not to assume you are all-knowing about an issue, so share what you know — this is an excellent way to facilitate conversation and potentially discover what you don’t know.
  3. Reasonably accurate expectations (estimates to complete). In the agile world, estimation can be challenging.  This is primarily due to the lack of data present at the beginning of tasks.  The easy way to overcome this and become more accurate with your estimation is to be sure to break down stories into common development tasks.  This may include an analysis, design, build out, unit test, etc type task.  I also like the proto-type, stub, or even the sub-functional task where a small piece of functionality is implemented.  Estimates generally get better the smaller the task and they are of course better when more than one person sets the estimate (leveraging the experiences of others will help).  Finally, always accurately update estimates to complete daily.
  4. Deliver within the boundries of the commitment. Simply stated, don’t always try to be a hero and deliver beyond the expectations of the original commitment. This can be viewed by management (be it product or development) as sand bagging estimates, or simply going rogue and “doing as you want to”. Not to say that finding a great way to do something that was much more productive is not a good thing or seeing that you can do a lot more within the context of the product functional area is not appreciated. But the right way to handle this is to disclose that you found a faster way to do something and your estimate-to-complete is much less than orginally anticipated, so you would like to work on another key capability that is similar to the functionality being implemented. Negotiating this within the context of the daily standup (and possibly within a follow up meeting) would be the correct course of action.
  5. Consistency is key.  Having one good sprint is not enough, a team needs to establish a trend of delivering on sprint tasks on a consistent basis.  This applies to the team as well as the individual.  Once a team is able to demonstrate a consistent trend surrounding capacity, story points delivered, hours worked, etc — the product stakeholders can start to reasonably expect that what the team says they will finish will in fact be delivered.

Remember the idea of trust should also exist within the scrum team and between scrum teams where there is a need to share deliverables or even if you all work within the same development organization. The five ideas above should be applicable to ensuring that all scrum teams work well together and within the overall scope of an organization.

What techniques or ideas do you have about how to build trust with the product management or project stakeholders?  What have you’ve done that works?

AgilePalooza in Atlanta


NOTE:  This blog was originally posted on March 17, 2010

Several weeks ago, I attended AgilePalooza in Atlanta with some of my co-workers.  It was a well put together conference and, I must say, a very cost-friendly conference.  This was  a one day event, that was primarily put together by VersionOne.  I attended three sessions, and learned:

  1. It’s good to get away from the office to simply press the reset button.  Even if it is for an afternoon.
  2. COMMON SENSE RULES!  The basic principals of do what you say, treat others as you wish to be treated, enjoy life (which includes work since we spend a lot of time at it), and remember that tomorrow brings another opportunity and today is a blessing.
  3. Some people need to practice their speeches and make darn sure they are relevant to the topic as promised.

I have both Mike Cottmeyer and Lee Hensen (a.k.a. Agile Dad) in my “Like Minded” links.  Both of these guys gave advanced topic presentations and they were very good.

Mike’s focused on scaling agile across the enterprise.  The interesting thing is that at my work, we are doing this fairly well — specifically, buy in to the process and seeing value of implementing in other areas.  But even more interesting, it seems the adoption of agile in big organizations seems very hit-or-miss, and primarily miss.  I’ve worked in mostly large organizations until now, and I can tell you — I have felt the frustration and dismay that some of the folks in the room have.  But you can make the case, and prove it can work — but you have to continue forging forward and not give up.  Ensure you have all folks seeing the value and establishing the trust.

Lee’s discussion was a re-hash of one I’ve seen him present at the agile conference in Orlando last year.  He updated, expanded, and expounded the content.  It was a good refresher and a solid reminder that ownership and accountability must be at a team and individual level, not one or the other – but both.  I know common sense, but repeated the need to establish trust amongst all of the parties involved and ensure communication occurs constantly.  And importantly, keep focus on the value of the project or work product.  One other thing he demonstrated is his method for estimating, very good and worth putting to practice.  I’ll write more about that later and reach out to him to comment.

Here’s the links to their presentations at the AgilePalooza website:

BTW – This ‘palooza was nothing like my first Lollapalooza experience in ’94 – George Clinton, Beastie Boys, Smashing Pumpkins, L7, Cyprus Hill, Black Crowes and Green Day – just to name a few.  That was a great time!

Agile Software Manufacturing

Early in my career, I was lucky to be able to work for a process manufacturing company that invented and produced engineered lumber products. Today I use many of my experiences on the manufacturing floor in my agile software development life. I know what you are thinking, how can you equate the manufacturing of engineered lumber products with development of software. Well you don’t have to look far to see that the whole product and software development communities have embraced efficient process manufacturing production line principles in the development of software projects and or products. This is a move from the world where building software was like building a house — lots of up front work regarding requirements and design, checkpoints and sign-offs along the way, and quality check offs at the end.

Scrum, Test Driven Development, Kanban, and eXtreme Programming — all of which are similar to the processes and best practices followed on a manufacturing floor. How are they similar? I’m glad you asked, over my next several posts I plan on exploring how they are similar and what we can learn from what transpires on the manufacturing floor.

Let’s first focus on what seems to be the most commonly implemented Agile practice – Scrum. I’m not going to get too much into what Scrum is – there are plenty of resources available for that and I’m sure one day that will be a good discussion for Agile.Agile.Agile.  So with Scrum, there are three areas which really stand-out:

  • Daily Standup (or Scrum) = Shift Production Meeting. All most all teams that practice Agile have daily meetings during which the team members answer the questions of “what happened since we last met”, “what is planned between now and the next time we meet”, and “what is preventing progress towards the goal”. Well these are the same questions answered during a shift production meeting at a manufacturing facility. They discuss the results from their previous shift, the happenings of the shift prior, planned production, and obstacles/challenges to meet the production goals. Much like the daily standup, issues are raised during the shift production meeting, but the discussion surrounding the actions to resolve are reserved until after the meeting and only those parties that can impact the resolution are involved. The primary reasons these meetings are similar are simple — it’s all about daily collaboration, team building, and ensuring the goals of the team are always in front of them.
  • Do what you said you would do. Well parents around the world have been saying this for a long time, but this is a core tenant of Scrum and working on a manufacturing floor. Actually, Scrum is about commitments and an agreement between the Product Development Team and the Product Owner (or Ownership Team). The crew that works on a manufacturing floor are committed to producing what was planned in the production schedule.
  • Plan in short periods that result in potentially shippable product. A key to meeting production goals is setting realistic goals that are derived from understanding production input constraints (raw materials and workforce) and an honest assessment of market conditions (understanding supply and demand of produced products as well as organization production goals). To do this successfully, planning is most effective when it is done within short time fences. Of course, all practicing agilistas know this to be true within most agile processes – and the sprint timeline is considered untouchable. This is because what was mentioned above – the team planned and committed to complete work within the specified sprint. It is also important to mention that using consistent short periods helps teams, production floor and or Scrum team, to get into a rhythm.
1 12 13 14