All posts by mikehking

http://about.me/mikehkingdotcom

Interview with Tom Cagley re: Scaling Agile

I recently chatted with Tom Cagley on the Software Process and Measurement Podcast (SPaMCAST) about some of my experience helping scale operations at Halfaker using best practices from various business books (e.g. Good to Great), frameworks (e.g. CMMI), techniques (e.g. Agile Scrum), and tools (e.g. JIRA).  I really enjoyed our discussion on why I was excited to JIRA, a tool that is not very opinionated, so we could configure it in some specific ways for individual Halfaker departments and projects.

The SPaMCAST is a great resource for learning more from great thought leaders in the Agile, Process Improvement, and Software Engineering world. Check out the interview at:

And if you’re looking for a Podcast app recommendation, check out Castro for iPhone/iPad.  It has this great “Inbox” concept (works like an Agile backlog, where you can accept things into the backlog and then prioritize/re-prioritize them.

Advertisements

Books, Podcasts, and Conferences related to Designing Great Organizations

Here’s a list of books, podcasts, conferences, frameworks, methodologies, models, and other resources related to designing and building great organizations that I think are worth checking out.

If you have any recommended additions, please email or send me a tweet.

Books, Frameworks, and Standards

Resource

Key Takeaways

Additional References, Summaries, Notes

The Scrum Guide
  •  Defines Agile Scrum implementation, including relevant ceremonies (meetings), roles (Product Owner, Scrum Master, and Team Member), and information radiators (tools)
  • David Anderson gave a great keynote at the CMMI Capability Counts 2017 conference — Kanban is often over-simplified for people who don’t appreciate the whole concept
  •  The Amazon reviews complain about the Kindle version of this, but I’m guessing they’re using the traditional Kindle — the figures look great on my Kindle Fire
Scaled Agile Frameworksafe-logo.PNG
  • Framework for scaling Agile practices to teams of over 50 people
  • Combines best practices from several other sources (e.g. Lean, DevOps, Scrum, Kanban) along with some good tactical recommendations, such as investing in a 2 day, in-person planning events every quarter for the whole team (Program Increment Planning)
Disciplined Agile (DA) process decision framework

DA-logo.PNG

  • Map (analyze) your operation, find the worst bottleneck, resolve it, and repeat
  • Optimize the system, not locally (don’t try to keep each individual machine or person “busy” or productive; instead focus on optimizing the whole system)
  • This is a classic book, written as a fictional story to teach the concepts of the Theory of Constraints
  • Note: A graphic novel version of this was recently released, which sounds interesting
  • Teaches the mindset and concepts of DevOps and why DevOps is so critical to increasing organizational agility
  • Quality Management standard, originally focused for manufacturing organizations, that provide a template on how to define best practices related to ensuring Quality in your organization’s operations, leveraging concepts such as formalized surveys asking your customers how you’re doing
  • Significant overlap with CMMI PPQA, but has some unique practices
x
 
 
 
 

Podcasts

Podcast

Key Takeaways

Additional References, Summaries, Notes

Cover Image
  • Fascinating podcast by Reid Hoffman, where he interviews leaders who have scaled their organizations
Software and Process Measurement Podcast (SPaM CAST)

spamcast-logo.PNG

  • Tom Cagley interviews people related to process improvement and lots of related domains

Conferences

 Conference

Key Takeaways

Additional References, Summaries, Notes

Agile Alliance’s Annual Conference
LeanAgileDC
CMMI Capability Counts Conference
DevOpsDays

Are you Running in the Right Direction?

Early in my career, I was a leadership development conference (through Lockheed’s great Engineering Leadership Development Program), where we played a game called Gold of the Desert Kings  — it was a group game, in a big event space ballroom packed with engineers from all over the country.  I don’t remember the rules of the game, but I do remember that it was a powerful reminder of how important it is to plan before you start working.

It’s easy to say we should plan before we start doing work — people say things like that all the time:

  • Look before you leap
  • Measure twice, cut once
  • Cal Newport made this point on Ramit Sethi’s blog a while back
  • Agile Scrum “forces” people, every few weeks, to stop and assess where they’ve been (sprint demo), where they’re going (sprint planning), and how they could improve (sprint retrospective)

But while we talk about this often, most people often regress back to a tendency of “jumping in” under pressure, instead of taking a breath and investing the energy of actually building a plan.

At the individual level, people are very quick to start working, trying to “make progress” and “feel productive” without investing the time to validate that they’re working on the most valuable thing. When groups of people (teams) are involved, we’re even worse at this — not only does the team want to jump in to avoid the plan of group planning and not feeling productive, everyone wants everyone else on the team to be productive (busy) so they feel they’re not the only one working hard.  This creates this nasty culture where the team is trying to keep everyone busy (Instead, Goldratt’s The Goal teaches that we need to optimize the entire system, not at the individual person or machine level).

Yes the plan will change, but it’s not the first version of the plan is not the valuable part — it’s the exercise of pulling together all the different pieces of a project and thinking about them together that is valuable.

While making progress on some new task feels more rewarding and productive than building a plan, whether it’s an Agile backlog; a resource-leveled Microsoft Project file; and/or a few quick PowerPoint slides summarizing major activities, schedule, resources, and budget; INVEST the time to make a plan — make sure before you start sprinting in some direction that you’ve actually checked to see if that’s where you should be running.

Shadow IT should be a Flashlight

Microsoft recently posted 3 ways to outsmart shadow IT, which talks some technology ways that CIOs can fight against Shadow IT (when employees use technologies not provided/controlled by the company to do their work, such as Dropbox or Gmail).

While security of company information is incredibly important, and Shadow IT must be controlled; it’s important to think of Shadow IT as not just something the Office of the CIO must fight against — Shadow IT should also illuminate areas where a company’s IT infrastructure isn’t supporting the needs of its employees well.

The IT Department should prioritize areas of frequent Shadow IT higher in their backlog to provide more capability — solve the root problem, not the symptoms

If employees frequently resort to shadow IT for project planning, or file transfer, or real-time document collaboration; the CIO team should consider not just email blasts, training, and security monitoring; they should also be considering getting additional capabilities out to their employees in that domain.  If it’s not obvious why a type of Shadow IT is persistent, think about asking ‘Why?’ five times to dig into the real reason people keeping trying to circumvent company tools.

How Opinionated are your Tools?

Organizations must intentionally determine how opinionated their collaboration tools (business systems) should be, to align with their culture and business model. Opinionated tools align well with top-down organizational cultures, while non-opinionated tools align well with decentralized, self-organizing cultures.

Organizations struggle at each extreme:

  1. Top-down organizations struggle to scale effectively, creating bottlenecks and issues when decisions constantly require senior leader approvals.  People talk about how our world is more volatile and faster moving (see Half of S&P 500 Companies will be Replaced in next 10 years), and that companies need to be more Agile.  Agility is hard when you need 3 approval signatures to make any changes. scaled-frameworks.PNG
  2. Self-organized teams struggle to stay coordinated, as each team can “wander off” from any centralized approach to things like enterprise priorities, technology architecture, processes.  They struggle to stay aligned with each other, which is why we see so many Scaled Agile frameworks (see icon mosaic to the right) trying to figure out how to keep self-organizing teams aligned with each other.  Self-organizing teams also struggle to stay aligned across an organization related to things like Enterprise Architecture (consistent technologies) and Business Architecture (consistent processes).

Organizations need to find the right balance between these two extremes for their entire organizational culture, and how they select, configure, and maintain tools to align with this approach.  The figure below shows the spectrum I envision, where a company moves the triangle to find the spot they want their organization to be, and then aligns tools with that spot on the spectrum.

opinionated tools spectrum.PNG

Technologies can come out of the box very opinionated (think about a tool like the TurboTax wizard interface, that walks users through a workflow it decides without asking how you want to use the tool) or it can be very flexible (think about Microsoft Word — you can write your letter first, and then format it; or you can setup the page size, orientation, and header before you write your letter).

Technologies can also be configured to be very opinionated — JIRA as an example is an issue/ticket tracking system that has a variety of Agile planning/management capabilities.  Out of the box, the tool comes with a few standard ticket types and workflows, but you could let each team in your organization configure their own ticket types, workflows; leaving all the permissions wide open for the organization.  However, most organizations make JIRA “more opinionated” before they deploy it, only letting a few select leaders/administrators make changes to the system.

On the opinionated this spectrum, I see organizations selecting and configuring tools with a heavy focus on ensuring employees use a tool exactly the way the organization’s senior leaders want them to be used (highly opinionated).   Allan Kelly recently write a great post about how dangerous this power centralization can become for organizations.

On the non-opinionated side, organizations struggle to stay cohesive.  They can become organizations of individual teams or almost a group of consultants who are trying to accomplish things; but can’t leverage the scale of their organization to accomplish great things.  This can devolve into anarchy, where teams don’t help each other.  Think about a team who can’t share talent with other teams, because they’re using different processes or technologies.  Or a leader who isn’t able to report on progress because each of her teams is using their project tracking tool completely differently.

Organizations, and the Office of the CIO organizations that should be enabling them, need find the balance, like a train station where the rules of engagement are clear (Where do I get a ticket? Where do I get on the train? Where do I get food?), but different people can get to their trains in different ways.  Organizations don’t have to be the wild west with teams doing whatever they want (think about a SharePoint site with no governance where you can’t find anything) and organizations don’t need to be top-down culture where no work gets done because everyone has given up on requesting approvals and resigns themselves to the slow-moving status-quo.

Serving Government Customers with SAFe Concepts

I recently spoke at the 2017 Capability Counts conference, put on by the CMMI Institute.  It’s a great event that isn’t focused just on CMMI maturity models — instead it’s a conference where a few hundred people get together to discuss process improvement, Agile, software engineering processes, and a variety of other related topics.

Here’s a packed room with Tom Cagley presenting on how to use storytelling to create better requirements:

Scaled Agile Framework (SAFe) is a great set of Agile and engineering best practices, pulling together great ideas from Lean, Scrum, eXtreme Programming, DevOps, and many others.  That said, I’ve found it to be a great mental model on how to structure large Agile programs and a useful of great ideas to pull from, rather than a framework to deploy entirely.  

I gave a presentation at the conference on some of the great ideas we’ve found in SAFe and how we’ve deployed them, while also giving a bit of a SAFe 101 for those interested.

Please note:  I’m not a SAFe certified trainer, nor do I speak on behalf of SAFe.

Welcome to “Designing Great Organizations”

Welcome to DesigningGreatOrganizations.com!

I’m Mike, and I’m excited to pull together great ideas from very smart people in the vein of Organizational Design, Organization Scaling, Agile transformation, and many other related domains in one place.

I’ve spent the last 10 years learning how about organizational design on-the-job, as a leader within an IT services organization based in Arlington, VA that has scaled up to over 250 employees.  Because of my lack of an organizational design/business executive background before this role, I’ve spent this time reading stacks of business books and studying other organizations to find great ideas that we could pull into the organization we’ve been growing.

I’m excited to organize and share what I’ve learned in connecting dots between frameworks, models, and business books like:

  • Agile Scrum
  • Scaled Agile Framework (SAFe)
  • Enterprise Kanban
  • CMMI