The Ideal Agile Marketing Tool

Estimated Reading Time: 3 minutes

Tools for Agile Marketing seems to be the hot topic in the various Agile Marketing communities. The Marketing Agility Podcast is talking to some tool vendors and people started to discuss it on the  Agile Marketing Facebook Group as well.

Here’s my view on what would be a great tool supporting Agile Marketing:

  • It would talk marketer’s language. Not force marketers to learn the language of development/IT.
  • It would be flexible. Marketers are not following Scrum to the letter. It should enable marketers to follow lean/agile principles without forcing the wrong practices.
  • It would be visual and beautiful because marketers appreciate those things. It wouldn’t bog down people with too many grids and lists and instead use more “Boards”.
  • It would support dynamic teams not just fixed scrum teams. Because that happens in Marketing. (also in Development btw)
  • It would support a combination of Scrum, Kanban without forcing you to choose one ore the other.
  • It would allow different teams in the organization easily adapt their area in the tool to support their own process.
  • It would TEACH marketers how to think about lean/agile flow/behavior. As a complement to frontal training, the tool should pro-actively support changing marketing culture to support agility.
  • Marketers spend even more of their time doing “Keep the lights on” activities such as cleaning up leads, monitoring campaigns, running webinars etc. A great tool would find an effective way not just to take that into account but also to help them manage those activities more effectively. Some of the Personal Kanban body of knowledge can help here.
  • Marketing Agility starts with individuals and can scale to hundreds of people. Not all tools need to support scale. But if the organizational agile tool can help the individual marketer become more agile it would help with adoption of the tool and agile marketing in general.
  • Emphasize simplicity, ease of use, streamlined flows. Otherwise it won’t stick. Having a situation where you have special people working the tool because the actual marketers won’t touch it with a stick is unacceptable (true story I heard in a recent meetup). It should take minutes to onboard a new team. It should take seconds for a marketer to add new work or move work along.
  • Integration into the other main tools of the 21st century marketer. Integration into email is one key thing. SalesForce when we start to talk about Account Based Marketing? Marketo/Hubspot/etc.? Integration into collaboration tools such as Slack/Flowdock?
  • It should provide some actionable insights – e.g. these items have been in flight for quite a while, worth looking at them in your next daily-stand-up. These items took a long time to cross the finish line – maybe worth discussing them in a retrospective/five-whys session. These items ping ponged a lot between states – worth looking at. There seems to be a lot queueing up for the designer. mmmm. maybe you should look at that (and suggest some tips along the lines of the theory of constraints five focusing steps). Why is it important to marketers? actually the more of those insights agile tools include the better it would be for everybody not just marketers. But since marketers are new to this agile thing, and many marketers aren’t necessarily process-oriented, this can help them along. (If they don’t have a lean/agile coach close by that is 😉

Consider this take 1. There’s probably more to think about when considering agile marketing tooling. I’ll add more when I think of it or see the need with the teams/organizations I’m working with.

 

 

Agile New England Meetup on July 14th in Boston – Lean, Agile, DevOps, Flow, Enterprise Kanban – What’s the connection and how do they all fit together?

Estimated Reading Time: 1 minute

Agile New England and the Boston Limited WIP Society invited me to give a talk on my next visit to Boston. The SES group in Siemens PLM (my client… ) graciously agreed to host the talk in their facility in Waltham on July 14th afternoon. Continue reading “Agile New England Meetup on July 14th in Boston – Lean, Agile, DevOps, Flow, Enterprise Kanban – What’s the connection and how do they all fit together?”

Who would have thought Personal Kanban would end up being the counter-measure to stalled Kaizen / Continuous Improvement?

Estimated Reading Time: 5 minutes

Paying attention to Management attention

I’ve been talking recently about the challenges of keeping sustainable sticky Continuous Improvement programs. An aspect I’ve mentioned but not emphasized enough is the lack of management attention. In this blog post I will focus on why management attention is so important in improvement programs, why is it lacking and what might we do about it.

Why we need management attention

Basically to change the system of work you need the attention of people that are in charge of it and can change it. If they don’t have enough capacity to work on the system you will end up stuck. You might find yourself focusing on local optimizations, you might even make progress in things that affect the overall system, but changing things like management decision filters, approach to targets (or lack of them…), relations between silos and the like will be difficult.

You might rightly ask: “Aren’t we supposed to trust the people working in the system and empower them to take charge of the system design and improvement?”. Yes we should! But getting to such a system typically requires significant change/transformation of how the system of “changing the system” works. You need attention of the people in charge of that system to change it. We’re back at square one aren’t we.

You might make a case for Guerilla warfare – working with people on the ground to change the system of work without showing up on the organization’s radar or at least without requiring formal support. That might work for initial “scouting” and establishing a case for new ways of working. I haven’t seen or heard of cases where the guerilla warfare was able to scale the change in a persistent healthy way throughout the organization.

So basically, can we agree that at least at some point of changing the system of work or system of improvement we need the people managing the system to start investing attention/capacity cycles in studying and improving?

For my inspiration on this term of “Management Attention” and it being the constraint of our systems you should watch Exploiting the Constraint: Management Attention by Eli Goldratt.

 

Why are we lacking Management Attention to Improvement work

Many managers don’t pay as much PERSONAL attention as we’d like to studying and improving the system of work or in the capabilities of their organization. Why is that?

Some managers thrive on urgency and opportunities for heroism. One can probably inquire about the ecosystem in which those managers thrive and who is responsible for changing that system. Basically as long as the organization cherishes and commends this kind of management rather than quiet steady capabilities-focused management we shouldn’t be surprised. The counter-measure? Seek to change this “policy” constraint which typically is driven from way up… This can be hard, but if you don’t deal with it don’t expect much traction.

Other managers DO care about improving the capabilities of their organization. They DO care about the system. They just don’t have the capacity / cycles to invest in it.

Let’s pause for a second and reflect on this issue from a different perspective. We’re all familiar with the team that is so busy delivering value that doesn’t have time to retrospect let alone take action towards improvement. What can such teams do? They can start by bringing their system of work under control using approaches like Kanban or Scrum. Then they can start allocating capacity to improvement. Scrum forces team to spend at least the “Retrospective” ceremony time for improvement but still many teams don’t take action based on the retrospective. Allocating capacity towards “Improving the system”/”Housekeeping”/”Engineering Improvements” or however you want to call it is key to getting actual results and feeling that the time spent in Retrospectives or Kaizen events is well spent. This allocation of capacity can be achieved in Kanban by always having one experiment in progress for example. Or one experiment in every Sprint Backlog if Scrum is more your cup of tea. So what can we learn from our advice to teams?

Personal Agility for Managers – Exploiting the constraint

A manager can start to bring his work under control by using an approach like Personal Kanban. Once under control he can start allocating capacity and attention towards improving. Improving his personal system of work, so he can free more and more capacity to strategic themes in his system of work. What might those be? For example driving and supporting improvement agendas of the organization he’s in charge of.

If managers are a key leverage point for improvement programs, we can also see them as bottlenecks/constraints for the “System of Improvement”. What we are suggesting here is to focus on this constraint and ensure managers achieve the best results they can with the time they have.

Decentralized Control – Subordinating to the Constraint

The next step is to subordinate to this constraint. Subordinating means to look at the system and finding opportunities to divert work from the constraint elsewhere, or do work in a way that makes the work of the constraint easier/faster. One way to achieve that is to Decentralize Control. If more and more work can be decentralized, we can free management attention/time. This can be “work” decisions such as what to pull, how to deal with conflicts etc. It can also be “improvement” work. They key though is to do it right. Not just decentralize but give good guidance as to the Intent of what we are trying to achieve. For a great talk on this subject watch Donald Reinertsen’s LSSC12 Talk.

 Takeaways for Lean/Agile Journeys

My current thinking is that helping managers improve their personal agility using approaches like “Personal Kanban” should be a key building block of successful improvement program. I started nudging managers I’m working with to consider this when I’ve seen them become the constraint for the “Improvement Journey”.

It shouldn’t come as a surprise that many of AgileSparks‘s current clients are exploring “Personal Kanban” in parallel to improving their wider systems. We are also working to help them pro-actively. AgileSparks coaches such as Danny Kovatch have been working on Personal Agility programs and approaches for a while now, Jim Benson exposed many people in israel to Personal Kanban in his Agile Israel 2012 talk as well as a workshop he ran when he was here.

A great side effect of working on something like “Personal Kanban” while running or preparing for a “Kanban Method” journey is that a key group of stakeholders for the journey are experiencing it first hand and leading by example. If they can “Limit WIP” and show to people they are doing it, there’s a higher chance that “Stop Starting Start Finishing” will stick on the team kanban board. Or on the portfolio board. It might be an interesting approach to start with Personal Kanban as preparation ground, even before management attention surfaces as the constraint. OTOH we might be working on a non-issue. If managers are not the constraint in a specific situation, should we still start with their personal agility? I can go either way on this, and would love to hear what other Kanban practitioners/consultants think.

Bottom line

There’s a good chance management attention is the constraint of your system. Identify if that is the case. Exploit it by offering managers “Personal Kanban” as an approach that can help them free scarce capacity. Subordinate to this constraint by Decentralizing Control intelligently while aligning using strong Intent. Leverage the cool side effect of having managers use similar approaches to take control of their work that their group is using to take control of its work.

TODO in a future post: How can we reliably identify if management attention IS the constraint? I have several thoughts on this, but will leave them to a future post.

Your turn

What do you think? Is management attention a typical system constraint? Is personal agility a good way to deal with it? Have you found other ways that worked for you?


How does the performance objectives process change in a Lean/Agile world?

Estimated Reading Time: 2 minutes

Seems like every January I get questions from HR leaders in organizations I’m working with that go something like this – “We are working on the yearly performance objectives process, and we were wondering whether it needs to change in an agile environment?”

The main evolution I see in the Performance management process is leaning towards measuring up and across as well as focusing on capabilities improvement rather than a set of concrete product deliverables specified up front.

Measuring up will motivate individuals to become better team players in their teams, as well as be better connected to their business objectives.

I personally preferred capabilities improvement over concrete deliverables for many years even before I’ve been exposed to agile, but of course it makes more sense. There are many situations where you cannot specify deliverables up front these days. You CAN aim for a certain capability or improvement trend.

Another trend I’m seeing and think is useful is to give teams shared goals on top of individual goals. These are again capability-driven goals as well as business objective goals.

A couple of years ago I compiled a list of examples that some HR leaders found useful. Maybe you will find them useful as well. Below are some references I used to build this list and I think are a good place to start for HR professionals interested in the performance/professional development aspects of agile. They are a bit dated I admit, and those following my writing and twitter presence will find more stuff.

UPDATE: HR people are really excited about the AgileSparks Agile Leadership development program called LAST (Leading Agile Software Teams)

Individual and team goals

View more documents from Yuval Yeret

References

http://www.poppendieck.com/measureup.htm - about how to measure/compensate in a group accountability environment
http://agilediary.wordpress.com/2009/01/07/individual-performance-in-agile-team-assessment-and-individual-burndown-charts/
http://runningagile.com/2008/01/22/review-process-for-agile-team-members/
http://theleanmanager.wordpress.com/2009/08/20/what-are-the-traits-of-a-lean-manager/
http://www.infoq.com/news/2008/10/performance_review
http://www.infoq.com/news/2009/08/agile-managers-role
http://www.infoq.com/presentations/poppendieck-agile-leadership
From my own blog – try to think about what something like the Toyota Improvement/Coaching Kata would mean for individual goal setting… http://yuvalyeretblog.wpengine.com/2012/01/10/the-toyota-kata-book-review-and-thoughts/
What resources do you find useful for HR in an agile environment?

“We are already Lean/Agile” – Really?

Estimated Reading Time: 3 minutes

These days more and more organizations think they are Agile

A couple of years ago when you talked to people about agile a common response “why should we”, “it won’t work here”, or “so this is the new fad? What will come next?”

Times have changed. And a sign of the fact that agile is becoming more mainstream is that it being diluted and a common response these days is “but we are already agile!”. I want to share a couple of questions to see if you are indeed agile.

What does it mean to be Lean/Agile

At a very high level what does it mean to be agile ? At a first level agile is an approach to development that embraces the complexity and uncertainty in both demand, specification and implementation implications by working in short cycles on small batches of work, constantly seeking fast feedback, and empowering people to work together focused on clear business goals, at a sustainable pace.

A second level of lean/agile is about embracing the complexity of the systems/processes used to take software from idea to realized value and using an inspect and adapt approach to let better approaches emerge. This is a much more pervasive aspect of lean/agile. Organizations fail to realize the real power and improvements are as a result of multiple iterations thru process experiments, always aiming to achieve goals of better delivery capabilities.

Are you delivering in an Agile way?

When you hear someone talking about being agile ask them:

  • Do your users/business stakeholders consider your delivery cycle fast enough?
  • Are you developing the Right things? Do you use your agility to drive small features to production to validate the value of a certain direction and then continue to deliver a pipeline of more small features while constantly evaluating feedback?
  • Are you doing things the right way? How much rework is there in your work? How much of the demand is generated by not doing things right the first time?

Are you improving in a Lean/Agile way?

And then ask some more questions that will dive deeper into the improvement aspects of lean/agile:

  • How often do you stop to reflect on our performance/capabilities?
  • Do you have a capabilities goal/condition you are striving for? How many people are aware of it?
  • How do u know your current state compared to that goal?
  • Do you run process experiments aimed at improvement towards a target condition we are focusing on?
  • How many of these process experiments do you try in a month?
  • What is the cycle time from deciding to work on a process improvement to finishing an iteration of the experiment on it?
  • What are the current main obstacles to improving towards your goal? How long have you known about them?

What it means

You might find that you have an “agile” organization that is not so agile when considering the service provided to the business.
In many of those cases when you dive deeper you will find a weak, unfocused or even nonexistent improvement engine/culture and a static process/system.

Doing scrum sprints, user stories, or kanban boards is just the starting point of the agile journey.

The main event is improving. Practices such us limiting work in process or focusing on a single sprint help with that.
There is a whole set of approaches beyond that – A3, five whys, retrospectives, operation reviews, statistical process control, the Toyota improvement kata, solutions focus, theory of constraints and many more – all used to improve.

Are you ready for the real world of lean/agile?

You might find this recent prezi useful to look at these multiple layers of improvement and the various approaches used.