Who is the Agile Manager?

Who is the Agile Manager?

Collaborative Leadership Team’s Dee Rhoda, Certified Scrum Professional & Agile Coach, shares her perspectives on the role of an Agile Manager.

We all know that there is a very important and prescribed position for managers in the traditional project management world.  These folks are masters of estimation.  They can estimate schedules, costs, resources and all manner of traditional project planning tasks and administration.  I once worked with a Project Manager who could whip up and submit a Change Request faster than my dog could nab a fallen piece of bacon off the floor!  That’s saying a lot because my dog is freaky fast!

Scrum Framework: Let it Work for You

Hi! I'm Christian Antoine. I'm an Agile instructor and Coach with the Collaborative Leadership Team.

I want to talk to you about the framework and how it's set up to help you. Let it work for you. When people learn a different way to approach their work, change brings about anxiety. I've learned to explain the framework this way to help people figure out that it's okay.

When we look at it this way, the framework is actually set up to make sure we don't get too far down the road before we find out if we're on track or not. And, when we look at it this way, we start with the product vision.  If we miss it in the vision, we'll catch it during the road map. If we miss anything in the road map, we'll catch it during the release plan. If we're missing anything in the release planning, we can catch it in sprint planning. If we miss it in sprint planning and we start the sprint, we'll catch it during the daily scrum. If we miss it during the sprint, we'll catch it at the sprint review. If there's something going on with the team, we'll catch it in sprint retro.

Either way, the whole intent of the framework is to make sure we're getting the right people to have consistent conversations to determine if they're building the right product and they're building the product right. So just start. Start with just enough, let the details flush out as you go and trust that the framework isn't going to let you hurt yourself.

 

Startups and TDD: Building The Next Big Thing with Disciplined Agile Engineering Practices

This blog article was re posted with permission from Rob Myers who will be offering the Certified Scrum Developer (CSD) course in March.  

Click here to learn more about the CSD course coming to the Twin Cities.

I've coached and trained so many start-ups who are in a later round of funding, or are building the next release of their software, and wish they had done things differently. Usually, I'm there to help them establish good Agile engineering practices (and help clean up the mess).

I understand the "just get it delivered" pressure on startups, and that they have to beat the competitors (both known and unknown) to market.  But I don't buy into the notion that excessive technical debt must be accrued in the first delivery. It's not necessary, because test-driven development (TDD), pair programming, continuous integration (CI) and other "Agile Engineering Practices" (a.k.a. "Scrum Developer Practices" a.k.a. "Extreme Programming (XP) Practices") all provide actual, tangible benefits; and much more quickly than most people expect.

In my developer courses, I often quote the Nagappan Paper:

The results of the case studies indicate that the pre-release defect density of the four products decreased between 40% and 90% relative to similar projects that did not use the TDD practice. Subjectively, the teams experienced a 15–35% increase in initial development time after adopting TDD.
-- research.microsoft.com/en-us/groups/ese/nagappan_tdd.pdf, Nagappan et al,  © Springer Science + Business Media, LLC 2008 

If I were seeing my fellow investors get that kind of return on investment, I'd want to get in too.  And early!

Of course, the choice of whether to take on technical debt or to "pay as you go" by adopting these practices from the start would depend on how long it takes for the practices to pay for themselves.  (And, yes, of course each has a cost.)

My friend and colleague, Arlo Belshee, and I were having a conversation about Agile transitions.  Arlo, like myself, is an old XP aficionado (at least, as far as I can tell...sometimes Arlo is hard to read), and we've both had amazing successes and wonderful experiences on full-blown XP teams.  I must have asked him which practices he would suggest the team implement first, assuming they needed to pick up these practices gradually.  He chose continuous integration and pair-programming.

I was a little surprised he didn't include TDD, because TDD resolves so many root causes of trouble on Agile teams. But his explanation won me over:  These two practices immediately provide very fast feedback loops and high-bandwidth communication for the team.

By emphasizing "immediately" I'm suggesting that these practices pay for themselves right away, so avoiding them because they appear costly is a poor bet.

In my own experience, TDD also starts to pay dividends almost immediately.  Even within my 3-day TDD course, many developers report that a single microtest caught something they could not have foreseen.  Software development has become too complex an endeavor to ignore the benefits of a comprehensive safety-net of unit-tests: It has eroded the Amazing Predictive Powers of most programmers.

One client who put all developers through the TDD course reported, after only about 4-6 months, that their latest release was the least defective release they had delivered in many years.  One developer said that a single trivial unit test had saved him from including a defect that would have crippled one high-end (i.e., $$$$) client, and he felt that disciplined TDD had likely saved him his job.

And by reflecting upon merely two of my own longer-term product development efforts that utilized XP, I can think of three cases where TDD+pairing+CI saved or made the organization a significant amount of money (at least $ 1/2 mil/year). Due to the malleability and maintainability of the software, our teams were able to accept a surprising, radical "mini Black Swan" user-story which:

  1. Opened up an entirely new market in a non-English-speaking country.
  2. Allowed doctors to more efficiently use our emergency-oriented software in their routine, day-to-day operations.
  3. Allowed a handful of highly-paid specialists to regain over 60% of their work-week that was previously spent manually transforming and re-entering patient data.

Each of those events was a surprise triple-win (for the customer, the organization, and the team), and each occurred within 6 months of adopting CI, TDD, and pairing.

If these disciplines reap benefits after such short periods of time, then the accrual of technical debt is only appropriate where the product can be written "in a garage" in a matter of days, and an upgrade will never be necessary.  Such products may exist, and they may even be quite useful and profitable (e.g., perhaps a smart-phone app).  I've never been involved in such a product's development, obviously because there would be no need for my kind of training and coaching.  But if I were called in to help develop one of these from scratch, would I still begin with good Agile engineering practices?  Yes!  Because I do not know what the future holds for that product, and I'd want to build in quality and maintainability, just in case we had built The Next Big Thing.

This blog post was re posted with permission from Rob Myers - click here to visit Rob Myers Agile Institute website. 

Collaborative Leadership Team hires ACIO, Thomas Auld, from University of Minnesota

Collaborative Leadership Team (CLT), an Agile and Scrum Consultancy, is pleased to announce the hiring of Thomas (Tom) Auld who will be joining Collaborative Leadership Team as Chief Operating Officer (COO) in January. In addition to COO duties, Tom will work with Clients as an Agile Coach & Trainer. 

For the last 25 years, Tom has been a servant leader in the Twin Cities IT landscape as both a Consultant and an employee.  Most recently, Tom completed his tenure as the Associate Chief Information Officer (ACIO) at the University of Minnesota.  As ACIO Tom was accountable for strategic enterprise initiatives such as the Institutional Review Board (IRB), Enterprise Data Warehouse, CRM, and Enterprise Asset Management.   In addition, Tom supported the creation of Agile teams and coached University Leaders on the value of using Agile principles to deliver capabilities for Students, Researchers, Teachers, Staff, and Minnesota residents. 

Prior to the University of Minnesota, Tom was a Principal Engagement Manager for a national consulting firm.  He had the privilege of delivering strategic capabilities for world-class organizations such as Target, Medtronic, Best Buy, General Mills, and TCF Bank.

As an IT Manager at Boston Scientific, Tom, built an Agile team to establish the Data Warehouse that delivered key analytics to the Sales and Finance organizations.

Angela Johnson, President and Founder of Collaborative Leadership Team, knows Tom shares CLT’s vision for the Agile framework in all aspects of Business, Software, and Product Development.  “Conversations around Agile are more frequently happening in the C-Suite.  Tom has the experience as an Agile practitioner and executive sponsoring Agile teams to help organizations transform the way they produce value for their Customer”   

CLT Partner, Agile Coach and Trainer, Christian Antoine adds “We look forward to Tom joining the team, and what that means for company growth. Tom improves our consulting, training, and coaching offerings to help our clients make real change in how they approach work.”

Tom is an experienced speaker and presenter.  At DreamForce 2016, Tom, along with other University CRM Leaders, delivered a presentation titled “ROI is King” to a full house of Higher Education Leaders looking for guidance on how to make the most of their CRM investment. 

For additional information on Tom’s new role in the Collaborative Leadership Team or to have him speak to your organization, please visit http://www.collaborativeleadershipteam.com/about-us/

About Collaborative Leadership Team-
The Collaborative Leadership Team is an Agile and Scrum Consultancy focused on optimizing Individuals and Teams, improving their ability to deliver valuable, working products.  For additional information on our service offerings, please visit our website
http://www.collaborativeleadershipteam.com or send us an email at info@coleadteam.com.

The Power of the Retro

When people are new to Scrum, the Sprint Retrospective can be viewed as an “Agile” meeting or a “Scrum” meeting. This may lead to rushing through the Retrospective or skipping them all together due to time constraints.

The Sprint Retrospective is the most important event in the Scrum Framework.  It gives the Scrum Team transparency into how they are doing work and the chance to inspect and adapt - improving their process. The intent is to have a process improvement, one “kaizen”, with each Retrospective thus improving the Scrum Team’s ability to continuously improve.

It’s important to keep Retrospectives from falling into a rut.  Keep them fresh and exciting. Avoid repeating the same Sprint Retrospective technique two sprints in a row. As Scrum Masters and coaches we want to challenge and push our teams to get better.  A great way to do that is introducing different formats to get people thinking differently.

Ideas for additional formats or facilitation techniques may be learned from coaches, other Scrum Masters, searching online or books focused on this topic such as Agile Retrospectives by Diana Larsen and Esther Derby.

 If the Scrum Master as active facilitator needs a fresh voice at a Retrospective or feels like they would like another perspective, how about asking another Scrum Master to lead a Retrospective?  Maybe there is a member of the team who would like to lead one.

 With a little preparation, Sprint Retrospectives will aide in any Scrum Team’s continuous improvement. To learn more about Scrum, please visit us at http://collaborativeleadershipteam.com.