Search

mikehking dot com

Personal Reflections: Agile, Leadership, Technology, and Life

Open Search
Category

productivity

Know when Working Harder isn’t going to Work

A dedicated employee who will work harder, with a greater sense of urgency (and maybe some extra hours when needed) is great.  But what’s much more valuable than someone with that work ethic, is someone who can see when working harder isn’t going to work, and they need to change their approach.

Think about someone using a dull saw to cut a huge pile of wood to build a house — they’ll look at the schedule and say “I don’t have time to sharpen my saw”, which is ridiculous to think about.  But we do it all the time when we try to shift into a higher gear and work harder to “dig out” of a busy season/project instead of thinking about what should we change.

It is so valuable as a leader to determine when a situation can be surged over, and when you need different resources/capacity/people/tools to overcome the situation.  Years ago, I was helping a Project Manager whose team was continually well below the needed velocity to get to the project’s finish line on time.  He kept trying to work nights and weekends to get back on the track, but simple math made it very clear that he could not single-handedly get the project back on track.  So we had to investing in both a technology and some additional people to help his team finish — it was easy to easy for those investments on his project; but it was much better to ask for them early in the project’s life as opposed at the end when he would be doomed to fail.

Think about if you need better processes/checklists, or a tool (e.g. software application) to help you be more efficient), or more people on your team, or something else.  Take the time to step back and think about how to change the game you’re playing so you can actually win.

Advertisements
0

Don’t Point at Problems, Attack Them!

There should be a word for people who have the annoying tendency to point at problems and talk about them, instead of trying to actually improve the situation (or maybe there is, and I just don’t know it).  I don’t know if you’ve been in a meeting with one of these people, but it’s so frustrating to listen to someone pontificate on and on about some problem and how it’s SO horrible, without trying to come up with any ideas, or asking someone to help them solve the problem, or just stop talking about it so someone else can try to solve the problem.

I’m not saying you should wait to bring a problem to your boss until you have a solution — for some teams/problems that’s a good idea, and for others that’s a horrible idea, and you need to get help for problems.  But what I am saying is that you should focus your attention and energy on fixing the problem, or removing the problem, or getting around the problem, or changing the situation so it’s not a problem anymore, or something else productive.

0

Email 101: Avoid the Bystander Effect

There’s a fundamental pyschology concept called “Bystander Effect“, where a group of people are less likely to help someone in need than when a single person is present.  Everyone in the group thinks someone else will/should help the victim, instead of them.

Think about this when you send an email — I recommend you clearly articulate who you want to do what, and ideally only put 1 person in the To: line of the email (even if you have a few people in the CC: line).

0

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
0

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.

0

Using JIRA to Scale your Business

I recently spoke at the 2017 Capability Counts conference, put on by the CMMI Institute. David Anderson Keynote 2017.PNG It’s an interesting 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.

The keynote (shown in the picture above) is David Anderson of LeanKanban University talking about the core concepts of Kanban, which go far beyond most people’s understanding of 3 column boards.

I spoke on using Atlassian’s JIRA product to help an organize scale — sharing some best practices/recommendations on how to use a tool like JIRA to get information out of email, hallway conversations, and meetings and into a system where work can be clarified, prioritized and tracked.

0

CIO 101 for Entrepreneurs

This morning I got to share IT infrastructure, business strategy, and business
architecture tips and recommendations with some local current and future entrepreneurs at The Capitol Post in Old Town Alexandria.  Capitol Post is a great organization focused on inspiring Veteran entrepreneurs to find professional clarity and scale those visions.  They offer several great things, including  a cool co-working space right in North Old Town Alexandria, classes, and a startup accelerator program.

img_9850

Here are the slides and strategy template I went through with the group this morning, helping entrepreneurs deal with IT.   We talked about:

We talked about how IT for non-technical entrepreneurs can be like personal finance for non-financial people — it’s very important, but it’s hard to motivate yourself to invest the time you need to understand it, make some solid plans, automate it, and then move on to creating value.

It’s been a year since I last taught at Capitol Post (https://mikehking.com/2015/09/11/talking-technology-bunker-labs/), and it’s great to see how much they’ve grown (the office is beautiful and their getting ready for their next cohort to go through the Bunker Labs DC accelerator.

0

Don’t get Stuck in the Past, Present, or Future

As I’ve gotten older, I’ve realized how each person has different tendencies.  Some of us are introverted.  Some are analytical.  In addition to personality axes like introverted vs. extroverted, thinking vs. feeling (see Myers-Briggs); people often have a tendency to either live in one of these times instead of balancing their time among them:

  • Past – Looking back at what has happened in your life, learning from mistakes and reflecting on what happened and what they learned about themselves through those experiences
  • Present – Engaging in the present, connecting with people and experiences as they happen
  • Future – Looking down the road and making plans, setting a vision and goals for your life

Each of these perspectives is important in moderation, but people sometimes get into trouble by being too focused one view — they can get stuck reliving the past (they miss life entirely, always looking behind them), living only in the moment (reacting to the present without looking down the road and making any plans) so life happens to them instead of creating the life they want, or only focusing in the future, so life passes them by while they make and refine plan after plan.  Don’t get stuck in only one of these — make time to look at all 3.

To quote the cinematic classic Spaceballs, which is almost partially relevant to this discussion:

Colonel Sandurz: Try here. Stop.

Dark Helmet: What the hell am I looking at? When does this happen in the movie?

Colonel Sandurz: Now. You’re looking at now, sir. Everything that happens now, is happening now.

Dark Helmet: What happened to then?

Colonel Sandurz: We passed then.

Dark Helmet: When?

Colonel Sandurz: Just now. We’re at now now.

Dark Helmet: Go back to then.

Colonel Sandurz: When?

Dark Helmet: Now.

Colonel Sandurz: Now?

Dark Helmet: Now.

Colonel Sandurz: I can’t.

Dark Helmet: Why?

Colonel Sandurz: We missed it.

Dark Helmet: When?

Colonel Sandurz: Just now.

Dark Helmet: When will then be now?

Colonel Sandurz: Soon.

Dark Helmet: How soon?

0

Organizational Operating System Upgrade?

I’ve started reading Brian Roberton’s book Holacracy, which talks about an organizational
management approach focused around self-organization and protected autonomy.  It’s an interesting attack on the base assumption that we should build companies in the traditional, top-down approach where a CEO directs leaders who direct other leaders, through layers and layers of business leaders.  Holacracy is the first non-traditional approach I’ve seen to business architecture (designing a company) that is cohesive and specific.  Managing teams with a methodology like Agile Scrum is powerful, but Scrum doesn’t scale to an entire organization, without armies of Scrum of Scrum Masters.  Early in the book, Brian lays out this metaphor of a business having its own operating system (including the org chart, business processes, etc.):

…the operating system underpinning an organization is easy to ignore, yet it’s the foundation on which we build our business processes (the “apps” of organization), and it shapes the human culture as well.  Perhaps because of its invisibility, we haven’t seen many robust alternatives or significant improvements to our modern top-down, predict-and-control “CEO is in charge” OS.  When we unconsciously accept that as our only choice, the best we can do is counteract some of its fundamental weaknesses by bolting on new processes or trying to improve organization-wide culture.  But just as many of our current software applications wouldn’t run well on MS_DOS, the new processes, techniques, or cultural changes we might try to adopt simply won’t run well on an operating system built around an older paradigm.

Brian describes an entire methodology, like some of the prescriptive ceremonies and roles you see in Agile Scrum; which I’m still wrapping my head around.  The core tenets of independent, autonomous roles seems incredibly powerful, because it seems to make companies much more scalable.  And it reminds me of the core factors that Daniel Pink identified in Drive as what employees wants in their job:

  1. Autonomy: People want to have control over their work
  2. Mastery: People want to get better at what they do
  3. Purpose: People want to be part of something that is bigger than they are

Holacracy’s concepts explained in 107 seconds: https://www.youtube.com/watch?v=MUHfVoQUj54

1

Powered by WordPress.com.

Up ↑