Steve and the Scrum Alliance are striving to build a Learning Consortium to explore the management implications of the emerging Creative Economy.
The members of the Learning Consortium will select five organizations from among these submissions and organize one-day site visits at their locations. Each host organization will make presentations and hold discussions about what it is doing, how it is doing it, and what it is learning. Membership of the consortium is limited to 30 organizations.
Each organization will be invited to send participants on the site visits. Once the site visits are complete, Scrum Alliance will organize a conference at which the Learning Consortium will make presentations and hold discussions about what has been learned. The Learning Consortium will produce a report of the conclusions of the visits and its review. The report will be made available to the 30 organizations.
Could your organization want to be one those 30 companies?
Are you curious? If so, please contact me, and I will be happy to put you in touch with Steve! Or here is more info:
- Steve presents the idea on Forbes.com.
- You can find the full concept on Steve Denning's website.
- You can find Financial Times columnist Andrew Hill's article supporting the idea online (paywall).
Could someone in your organization be interested in participating? If so, please drop me a line! And I will be happy to put you in touch with Steve directly.
EDIT: fixed missing links, formatting.
This article is meant for knowledge workers that want to be more on top of things and feel secure that they haven’t forgotten about something, freeing their mind for the actual tasks at hand. It especially applies to those that are using or want to use SCRUM, a popular and formalized Agile methodology, in their day to day work.
I got hooked on Agile back in 2005, while working for Db4o, and never looked back since. Improving the process per iteration and having a manageable amount of work per sprint gave me peace of mind and focus, enabling me to deliver the right software solutions to the stakeholders. When I got asked to join a tech startup in 2011 as its CTO I suddenly had a lot more to deal with: hiring and managing staff, managing costs, reporting to the board, applying for subsidies and making sure the books were kept in order. On top of this I still operated as SCRUM Master and technical lead within a SCRUM team.
During this period one of my co-founders introduced me to Getting things done by David Allen. It took him only about 15 minutes to explain the basics and I got started with it straight away.
You can optionally watch this presentation to go along with the article:
As knowledge workers, and more specifically consultants, we have a diversity of responsibilities. You have personal responsibilities, like planning a doctor’s appointment or picking up your kids from daycare, and you have responsibilities from your employer like ordering a backup disk, co-creating a course or preparing a presentation. Lastly you also have responsibilities from your client, like sprint tasks, meetings and organizing innovation days. Truly staying on top of all these responsibilities is tough, real tough!Agile
For those of you that are not familiar with Agile methodologies. Agile is an iterative process. In each iteration a team commits to a finite amount of work. A typical iteration has a length of two weeks, which is its deadline. All stories, the units of work in an iteration, can be made actionable by the Agile team.GTD
Getting Things Done takes a slightly different approach. There is a single inbox, comparable to the part of a backlog in SCRUM, that hasn’t been groomed yet. By regularly reviewing the inbox, it can be emptied by turning items into actionable tasks, high-level projects, calendar items, reference material or just trash. Actionable tasks can be extracted from a project, that will move it forward. Actionable tasks should be kept together to be able to prioritize them upon review.
Please refer to the book Getting Things Done by David Allen in order to get the full explanation but below follows a quick overview.Quick overview of GTD Inbox
The purpose of the GTD inbox is to collect anything new that might or might not require your attention. Whenever something pops up into your mind that you think requires your attention, either now or in the future, you collect it here. It doesn’t need to be organised. It doesn’t even need to be an attainable goal. As long as you get it off your mind and file it away for review, the inbox has done its job. Reviewing the inbox will empty it into one of the following categories.Trash
You may find that a lot of the things you collect in your GTD inbox don’t really require you to take any action at all, so you can throw them away with impunity! Good riddance!File
Many a time you get a piece of information that you don’t need immediately but would like to be able to reference in the future. These items go from your inbox into a file. This file can be physical, a folder structure on your computer system or something completely different.Calendar
Though people have a tendency to put too many things in their calendar that really don’t need to be done at that exact time, inbox items that do have a specific time window move from there to your calendar.Waiting for
If you delegate something you expect it to be done after a certain period of time. Though these dependencies are kept out of SCRUM for a good reason they are a part of everyday life. Move these from your inbox to your waiting for list so you can check in with whoever you delegated it to in order to be aware of their status.Someday maybe
Colleague sent you an adorable youtube frolicking puppy compilation? Maybe you didn’t have time to watch it when it was brought to your attention but why not put it away to watch later? Items that you don’t need to do but would like to get around to eventually should be moved over here.Projects
There are many things that people have on their to do list that they keep on staring at and get intimidated by for some reason. Often this pertains to items that are of a too high level to pick up straight away. This can range from Bring about world peace to Organise daughter’s birthday party. Both of these tasks really consist of multiple clearly actionable tasks even though one gets the impression the latter is easier to attain in one’s lifetime. Things that should be more clearly defined belong here. Review them and extract actionable tasks from them that move the projects closer to their goal.Next actions
This is the work horse of the GTD system and is where you actually pick up tasks to do. You place well defined tasks here. If you need to call someone about a case, be sure to save this tasks along with the name of the person, their phone number and case reference to remove any impediments, like having to look up their number or the case reference. This way you make the barrier to get something done as low as possible.Obstacles
Of course there are a few obstacles to overcome using these two methods side by side as a consultant.
Since GTD encourages you to work on the most important thing at that time, you could be required to make private phone calls during consultancy hours or respond to a mail from a co-worker while getting ready for work. This causes work-time and private time to overlap. The obvious solution would be to track work intervals for each task. However, this takes a little bit of time and discipline so should ideally be automated.
GTD requires you to review at least daily what should be done with stuff in your inbox and what the next most important actions are. This takes time. Is this personal time? Should it be billable? In my opinion working with GTD reduces stress and increases productivity and effectiveness. Thus working with GTD will make you a more valuable employee which is something your employer should invest in.
While both GTD as well as Agile work with definitions of work, the priority of stories in SCRUM is determined by the Product Owner. How can this be incorporated into GTD? Well, even though the Product Owner is in charge of the priorities inside the sprint, he does not have a full overview of everything that needs doing in your life. Therefore you are the one that determines the order in which your tasks need to be performed. Within these tasks only the ones coming from your sprint have a relative order pre-determined by the PO.Improvements
In my day to day usage of GTD I found that there are a few identifiable improvements.
Due to work requirements I need to maintain multiple calendars. Since some GTD inbox items end up in your calendar this sometimes means having to create multiple items in your calendar, which causes needless overhead. It would be beneficial if this would be supported by software, so that a GTD inbox item can automatically be delegated to one or more calendars.
When tasks are coming from external applications like Jira they have to be kept in sync. It would save time if this could be managed automatically.
Lastly the question of ownership. Who owns a task? The assignee, the author or the company on who’s behalf it needs to be performed? I strongly believe that tasks belong to the author or organisation that the author wrote them for. If tasks have been delegated or synced from external systems they should be revocable by their owner. At the same hand an organisation should not have or control access to tasks a person authored without the author’s permission.Conclusion
Unfortunately there is currently no software tool that would serve all my needs as outlined here. However the most essential properties of such a tool should be: multi-platform to ensure availability, tagging support to be able to categorise without having to split up the list and owned by you.
One nice thing about being in the consulting industry is that you typically end up with a little downtime around the holidays. Most of our customers slow down, and even if people are still working, there often isn’t much appetite for change. For me, the year can get pretty noisy and it’s really tough to get contiguous time to sit and think. I’ve grown to appreciate this time of year as a time to get my thoughts in order, figure out what’s important, and decide how I want to move forward. It’s really a sort of built in time to retrospect on the year past and plan a little for what lies ahead.
I’ve spent the past few days sitting in my office mind-mapping and getting some of this stuff onto paper. I’ve been thinking about LeadingAgile as a company and what it means to shape it’s future… what do I want, what do our people want… how do we build the best company we can possibly build? I’ve been thinking about our approach to agile, how to make it better, and how to communicate our emerging models to the community in a meaningful way. As our thinking has progressed, it’s become way more difficult to write contextually in the short format of a blog post. That poses some interesting challenges for us as we move into 2015.
The themes that keep coming back to me as I noodle on this stuff are around managing risk and uncertainty, how to decouple teams, how to minimize dependencies, how to focus on flow of value, and really how to get people to see how to do this and what’s the change management processes necessary to move the needle forward with companies in a meaningful way. I think the mechanics and value of team level agile are well understood at this point in our evolution. I think that we are starting to see some interesting scaling models that will help some companies some of the time get better business outcomes.
I think that the main challenge going into 2015 isn’t a better articulation of values and principles or a better articulation of potential scaling patterns… I think that the main challenge is engaging companies where they are today… deeply understanding why they are the way they are and their real underlying constraints… and helping them craft change management strategies for safely and pragmatically moving forward. As an industry we have rejected the status quo of the waterfall based SDLC. We’ve embraced agile and many of the emerging patterns for agile at scale. I don’t think we are talking enough about how we get there.
Part of the problem is belief based and part comes down to raw economics. As a community, we often want to believe that if we point people in the right direction, and get them to believe the right things, they will self-organize into the patterns we are prescribing. They’ll figure it out along the way. I think this will work with some companies some of the time… but many organizations are suffering from some severe constraints and timing issues that have to be managed. These companies have people steeped in the old way of doing things and not much incentive to put themselves at risk for a new model of dubious merit.
The other thing that gets in our way are the economics around training and certification. As business people, consulting and training companies, are looking to reduce risk, keep people busy, and stay profitable. Our market wants training, they want certification, and people want to believe that if you send folks to a few days of indoctrination, they’ll come back with the necessary skills to do agile. I think that educating people on how work within an established framework is valuable. Training people on a model that is not established, and expecting them to go back into their companies and lead the implementation of the framework, is doubtful.
I think as a community, we have to recognize that many of the companies that want to adopt agile are a long way from having the infrastructure, management paradigm, culture and practices to actually effectively do agile. Sometimes we have to meet them where they are and help them get them to where they need to be. One of the toughest pills to swallow as an agile company, helping other companies adopting agile, is that early on we might have to build a plan… even a Gantt Chart… for how the transformation is going to proceed. Sometimes getting traction and gaining trust involves playing by someone else’s rules for a while as you get started.
So… as I think about 2015 and the challenges that lie ahead for LeadingAgile and our industry… I’m going to try to lead some conversation around the intermediate states as a company transitions to agile. I’m going to try to get more explicit around the patterns of transformation and how a company goes from point A to point B or C on that journey. I don’t think that all of this exploration is going to be via the blog. We’ve build some infrastructure on the site to accommodate video, white papers, and presentations and we’ll try to communicate in whatever medium is fastest to market and makes the most sense.
Not sure exactly what all this means, but we are going to explore some mediums we haven’t explored yet, and try some new things. We’ll probably makes some mistakes and say some stupid stuff along the way. When you catch it, just let us know and we’ll do what we can do to get it cleaned up. There is a reason we decided to call our blog post Field Notes. We have an amazing client list and some customers that are really committed to working along side us to figure all this out. It’s time we start sharing some of what we are learning. The site as a whole will be the channel for this, but we’ll try to put pointers on the blog to keep everyone posted.
Anyway… hope everyone is tee’ing up for a great 2015. We wish everyone the best and hope you have a great new year!
I did a major cleanup of my post on lessons learned from John Maxwell:
It should be much easier to read now.
It was worth cleaning up because John Maxwell is one of the deepest thinkers in the leadership space. He’s published more than 50 books on leadership and he lives and breathes leadership in business and in life.
When I first started studying leadership long ago, John Maxwell’s definition of leadership was the most precise I found:
“Leadership is influence.”
As I began to dig through his work, I was amazed at the nuggets and gems and words of wisdom that he shared in so many books. I started with Your Road Map for Success. I think my next book was The 21 Irrefutable Laws of Leadership. Ironically, I didn’t realize it was the same author until I started to notice on my shelf that I had a growing collection of leadership books, all by John Maxwell.
It was like finding the leadership Sherpa.
Sure enough, over the years, he continued to fill the shelves at Barnes & Nobles, with book after book on all the various nooks and crannies of leadership.
This was about the same time that I noticed how Edward de Bono had filled the shelves with books on thinking. I realized that some people really share there life’s work as a rich library that is a timeless gift for the world. I also realized that it really helps people stand out in their field or discipline when they contribute so many guides and guidance to the art and science of whatever their specific focus is.
What I like about John Maxwell’s work is that it’s plain English and down to Earth. He writes in a very conversational way, and you can actually see his own progress throughout his books. In Your Road Map for Success, it’s a great example of how he doesn’t treat leadership as something that comes naturally. He works hard at it, to build his own knowledge base of patterns, practices, ideas, concepts, and inspirational stories.
While he’s created a wealth of wisdom to help advance the practice of leadership, I think perhaps his greatest contribution is The 21 Irrefutable Laws of Leadership. It’s truly a work of art, and he does an amazing job of distilling down the principles that serve as the backbone of effective leadership.
Have you experienced problems with competition amongst team members/developers within a Sprint. A Sprint is a race, after all. Most people associate this term to mean a short dash, going as fast as you can, competing against a number of others. There’s a great new show called Silicon Valley (by Mike Judge of Beavis and Butthead fame) that shows this dysfunction on a Scrum team.
http://youtu.be/oyVksFviJVE (Warning: funny, but slightly inappropriate in areas)
After watching this, ask yourself, are we truly a team trying to achieve a common goal, or are we still individuals competing amongst one another? How do we measure progress? How do we reward folks? How do we handle the type of dysfunctional behavior in the above video, and who does it? Is this is a reason to begin using the term Iteration instead of Sprint?
In my experience, I’ve not seen the competition quite so blatant amongst developers as in the aforementioned video. But I have seen it. And as a Scrum Master and an Agile Coach, I have pointed them back to the Agile Manifesto’s 12 Principles…
The one that stands out, to this point is…
Working software is the primary measure of progress.
In other words, we’re not measuring lines of code written, or story points completed, or hours worked. We’re measuring working software completed, at the Team level. Did we, as a Team, meet our Sprint goal, and deliver something valuable to our customer through early and continuous delivery.
Velocity is another metric that gets misconstrued, in my experience. At the end of the day, velocity is a planning metric for the Team. We shouldn’t use it as a measure of speed compared to another team or another individual; i.e. I’m a great developer because I was able to complete 4 stories for a total of 20 story points in this 2 week Iteration. The guy sitting next to me only got 10 story points done. Therefore, as their logic goes, I’m twice as good a developer as him. And I should be compensated accordingly when it comes bonus time.
Yeah, but what if we have slackers on our team, and there’s really only one or two people doing a majority of the work? Well, there’s probably a reason for this behavior, actual or perceived. My advice is to dig in to the root cause. Clearly fodder for the Retrospective at the end of the Iteration (a.k.a. Sprint). Beyond that, it’s really up to the Team to resolve if they can. Escalate as necessary.
My initial assumption starts with the idea that we have self-motivated individuals on our Teams. And that it’s my job as a Scrum Master to provide them the environment and support they need to get the job done. If I can’t do that myself, I get help. Servant leadership.
What experiences have you had with intra-team competition?
Everybody has a story. I thought I would share mine at Sources of Insight:
It’s the story of how I figured out how to do more of what makes me come alive, and how to share my unique value with the world.
It’s a journey, but this story is a look backwards, and how it helped me shape my path forward.
I included some of the key questions I asked, as well as some of the key resources I used to get a new lens on work and life.
Life can really be a game of chutes and ladders, depending on the questions you ask, the choices you make, and the actions you take.
I think one of the biggest challenges we have in life, is a very personal one. It’s the challenge of finding our voice. It’s the challenge of finding our passion, our purpose, and our talents. It’s the challenge of becoming all that we’re capable of. And, it’s the challenge of how to make the most of what we’ve got, while helping others in our unique way.
The other big challenge is avoiding regret, learning to live with regret, or learning how to live without regret. What we regret the most, are the things we have a chance to change. It’s our opportunities lost. Or, to put it another way, we regret the things we didn’t do. That can include things like not being true to ourselves, not expressing our feelings, not staying in touch with friends, or not letting ourselves be happier.
The top regrets in life based on research are: education, career, romance, parenting, self-improvement, leisure, finance, health, friends, spirituality, and community. Education is the top regret because it impacts so many areas of our life, and it’s within our control.
The way I learned to write my story forward is to combine a combination of answering the following questions on an on-gong basis:
- Who do I want to be and what experiences do I want to create?
- Am I giving my best where you have my best to give?
- Am I living my values?
- Am I saying “Yes” to opportunities?
- Am I sharing what I think and feel to the people in my life?
Transformation is a journey of challenges and changes. And that’s where our greatest growth comes from.
Best wishes for your best year, ever.
New Agile Certification Training
Our new premium offering: the Certified Real Agility Coach course is delivered in an unusual format of 40 days (yes, forty) spread over one year. This in-depth, advanced training program is designed to help people with experience on Agile teams to become fully-capable independent Agile coaches. Worried about the time commitment? A substantial portion of the course is delivered as on-the-job training and a significant number of course hours are outside regular working hours… and the schedule is flexible to accommodate participants’ unique scheduling needs. Spots are extremely limited for this course. Reserve your spot now! (Contributes all the training hours required for the Certified Scrum Professional designation. As well, if you do not already have the CSM and CSPO designations, you will receive free enrolment in either or both of those courses once your registration has been confirmed.)
Since Travis Birch and Mishkin Berteig have become Certified SAFE Program Consultants, we are now offering the Leading Safe 2-day course for project, program and functional managers, change agents and department leaders. Learn about the Scaled Agile Framework; one the most popular enterprise Agile frameworks. SAFe combines Scrum, Extreme Programming and Lean to effectively allow larger groups of people to execute programs while interfacing effectively with traditional corporate governance. Do you have 25 people or more working on a program? Then the Leading SAFe training is for you!
New Agile Introduction Courses
Scrum and Enterprise Agile for Executives is a half-day workshop designed to help you solve one of the biggest problems organizations have: how to become more Agile? Using the tools and techniques of the Real Agility Program, participants will be guided to make effective long- and short-term plans for increasing productivity, innovation, quality and customer satisfaction. This workshop is delivered by Mishkin Berteig who has helped numerous executives at organizations large and small with successful Agile transformations. Just $250 per person!
Travis Birch, a Partner at Berteig Consulting who has years of experience helping Agile teams reach award-winning levels of performance, is going to be delivering two of our new offerings:
Choosing an Agile Career is a one-day workshop designed to help people who don’t yet know how they can best fit into the most important revolution sweeping the corporate world. Should you be a ScrumMaster? A Product Owner? An Agile Coach? Something else? Ideal for people who have been asked by their executives to sort out their career path in a newly Agile organization or department. $450/person with an early-bird discount available for some dates.
Kanban: Gentle Change is a deep-dive immersion into a critical process-improvement and teamwork technique Learn how tools for making work visible can improve productivity, throughput and efficiency.. Ideally suited for team leads, project and functional managers, HR managers and process improvement managers. $450/person with an early-bird discount available for some dates. Counts as 7 PDUs with the PMI and contributes to the Agile Certified Practitioner designation.
Of course, we continue to offer our extremely well-received (often sold out!) Certified ScrumMaster and Certified Scrum Product Owner training courses. These courses are immersive, intensive, and designed to help you to become great ScrumMasters and Product Owners.
Please see our complete 2015 Agile and Scrum course schedule here! Most of our courses are held in the Toronto area which has a great international airport, fantastic food, amazing entertainment, and is just generally a fun place to come for a bit of training and a bit of sight-seeing. Some courses are also offered in other cities including Vancouver, London Ontario, and Waterloo. Most of our courses are also available for in-house private dates. Please contact firstname.lastname@example.org for more information about group discounts, corporate savings programs or in-house private offerings.
COMING SOON We are working to offer Certified Scrum Developer (CSD) training as a complement to our already successful Certified ScrumMaster and Certified Scrum Product Owner training courses. The CSD course will help technology professionals learn the critical Agile engineering and teamwork practices that are absolutely required to make Scrum successful in delivering software products. This training is highly technical and participants are expected to already be strong software developers.Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
“Another year over, And a new one just begun.” – John Lennon
Ready to get your game on?
January is a great time to focus on what you want out of this year. As you close out last year, you can reflect on what went well and what things you could improve. Focus on the growth.
January is also a great time to build some momentum. January and December are the bookends for your year. It’s interesting how they are both a month apart and a year apart.
What you fill that year with, is your opportunity.
If you’re having a hard time remembering what it means to dream big, I put together a collection of dream big quotes to rekindle your imagination.
I’ve also put together a set of posts to help you create goals with skill:
- 10 Reasons that Stop You from Reaching Your Goals - I see so many people who achieve their goals, and so many people who don’t. I thought it would be helpful to nail down why so many people don’t achieve their goals, even when they have such good intentions.
- Are You Living Your Dreams? - Here is a blurb I found from Dr. Lisa Christiansen that helps remind us to dream big, dream often, and live our dreams.
- Change Your Strategy, Change Your Story, Change Your State - If you want to change your life, you have to change your strategy, you have to change your story, and you have to change your state.
- Goal-Setting vs. Goal-Planning - Most people don’t step into what achieving their goal would actually take, so they get frustrated or disheartened when they bump into the first obstacles. Worse, they usually don’t align their schedule and their habits or environment to help them. They want their goals, they think about their goals, but they don’t put enough structure in place to support them when they need it most, especially if it’s a big habit change. Don’t let this be you.
- How Brian Tracy Sets Goals - Brian Tracy has an twelve-step goal-setting methodology that he’s taught to more than a million people. If you follow his approach … You will amaze yourself. With his goal-setting methodology, he’s seen people transform. They are astounded by what they start to accomplish. They become a more powerful, positive, and effective person. They feel like a winner every hour of the day. They have a tremendous sense of personal control and direction. They have more energy and enthusiasm.
- How John Maxwell Sets Goals - John Maxwell is an internationally recognized leadership expert, speaker, and author. And, one of his specialties is turning dreams into reality through a simple process of setting goals.
- How Tony Robbins Sets Goals - This goal-setting approach is one of the most effective ways to motivate you from the inside out and move you to action, so if you have a case of the blahs, or if you want big changes in your life this might just be your answer.
- How Tony Robbins Transformed His Life with Goals - Tony Robbins wanted to change his life with a passion. He had hit rock bottom. He was frustrated and feeling like a failure. He was physically, emotionally, spiritually, and financially “broke.” He was alone and almost 40 pounds over-weight. He was living in a small, studio apartment where he had to wash his dishes in the bathtub, because there was no kitchen. He wanted out.
- The Power of Dreams - John Maxwell shares what he’s learned about the power of dreams to shape our goals, to shape our work, and to shape our lives.
- The Real Price of Your Dreams - Tony Robbins walks through helping a young entrepreneur translate their dream of living like a billionaire into what their lifestyle might actually cost.
One of the most helpful things I’ve found with goal setting, is to start with 3 dreams or 3 wins for the year. I learned this while I was putting together Getting Results the Agile Way: A Personal Results System for Work and Life. As my story goes, I got frustrated and bogged down by a heavy goal process and lost in creating SMART goals. I finally stepped back and just asked myself, what are Three Wins or Three Outcomes that I want out of this year? The first things that came to mind were 1) ship my book, 2) get to my fighting weight, and 3) take an epic adventure.
It wasn’t scientific, but it was significant, and it was simple. But most of all, it was empowering.
In retrospect, it seems so obvious now, but what I was missing in my goals was the part that always needs to happen first: Dream big. We need to first put our dreams on the table because that’s where meaningful goals are born from. It’s the dreams that make our goals a force to be reckoned with. Really, goals are just a way to break our dreams down into chunks of change we can deal with, and to help guide us on our journey towards the end in mind. That’s why we have to keep pushing our dreams beyond our limits. That way we don’t try to push ourselves with our goals. Instead, we pull ourselves with our dreams.
If you want to know how to get started with Agile Results, before you get the book, you can use the Agile Results QuickStart guide. You can use it to create your personal results system. It’s a simple system, but a powerful one. Individuals, teams, and leaders use it to bring out their best and to make the mot of what they’ve got.
To give you a quick example, if you want to rise above the noise of your day, just take a quick pause, and write down Three Wins that you want out of today. If you’re day is pretty tough, you might say, “great breakfast, great lunch, great dinner.” We have those days. Or, if you’re feeling pretty good, you might say, “ship feature X” or “clear my backlog” or “finish my presentation” or “win a raving fan”, etc.
It sounds simple but by having Three Wins to hold onto for today, it helps you focus. It helps you prioritize. And it helps you get back on track, when you get off track. It also gives you a quick way to feel good about your achievements at the end of the day, because you can actually name them. They are your private victories.
So, if you want to practice Agile Results, just remember to think in threes: Three Wins for the Day, Three Wins for the Week, Three Wins for the Month, Three Wins for the Year. It will help you funnel and focus your time and energy on meaningful results that matter. And, you’ll build momentum a moment at a time, as you respond to challenges, exercises your choices, and drive your changes in work and in life.
As we look into 2015, there is a lot of excitement, a lot of opportunity, and a lot of fun ahead of us. I’m glad to be a part of it as I begin rolling into the Agile For All fold.
We have a lot of great stuff happening, obviously our retinue of services have now been bolstered by even more expertise and our service offerings will continue to grow for our current and future clients.
Here’s what you can expect from us moving into 2015:
- The highest quality Agile/Scrum/Management training out there
- More experimenting on how to service our clients even better
- More content generation and thought leadership
- Exciting new service offerings (yay)!
- And even more…
I’m super excited for what 2015 will bring. For those that don’t know the newest addition to the wonderful Agile For All crew, you can find more information about me here in the Agile For All bio, and more here in an expanded version.
A couple of things I’m excited to bring into the fold:
- Helping our clients understand the complexities of systems at scale. – Just because you’re big doesn’t mean you overlay scaled processes. This can (and often will) make the complex even more complex…
- Bringing a deeper understanding of the sciences behind organizational agility, human capital, and cultural optimization.
- Growing education in and within organizations – Kaizen (continual improvement) should be a business strategy, not just an afterthought.
- And even more…
Let us know what you’d like to see, hear, or even experience as we continue to partner with many of you into 2015!
Thank you all! Here’s to a kick-booty 2015!
I had the privilege of speaking at Scrum Australia 2014 conference couple of months ago. It was a fascinating experience to stand in front of such an energetic and knowledgeable audience and share ideas. Scrum Australia team had put a lot of effort and energy in getting good speakers not only from Oceania but from abroad as well. I enjoyed every bit of this conference for 2 days.
The title of my topic was “Building products that customers love by strengthening Scrum with Design Thinking and Lean Startup methods” .
I believe that we need to combine various methods, and use their strengths to build the products. Scrum has its own strengths, and similarly Design Thinking and Lean Startup as well. However, none of these methods on their own can be used on their own to build great products.
First of all one needs to ensure that any new product idea is viable, desirable and technologically feasible.
It is very important that one has a good understanding of the problem one needs to solve. Most of the products fail mostly because of lack of understanding of the problems.
Design Thinking comes handy in articulating the problems, and Lean startup could be applied with product testing, pivoting.
I would like to thank Lynne Cazaly for beautifully depicting my session with the following “Visual Note”
I had put together this idea of bringing the 3 methods together (Scrum + Design Thinking + Lean Startup) long ago. This idea was published by Cutter as an Agile advisor. Cutter was also gracious enough to make this article public. The entire article is available here if any one is interested in getting into a detail a bit.
I have been attending Scrum Australia conference without fail since the last couple of years, and return with a load of new knowledge and experience. I am already looking forward for the 2015 conference :-)
I launched my first Ruby gem a few days ago, yertle_formatter. It’s a custom RSpec 3 formatter that prints out turtles for slow specs and then lists them in order of slowest specs.
I worked out a lot of experiments with:
With 2015 ahead I may be working on some new gems soon. As a first gem goes, writing a formatter was a nice way to get started and published.
Agile Advice was started in 2005. In ten years, we have published over 850 articles (an average of just about 2 per week!). Here are some collections of the ten “best” articles. I hope you enjoy looking back at (or discovering for the first time!) some of the things that have made this such a great joy for me.
Ten Most Popular Agile Advice Articles
- How Two Hours Can Waste Two Weeks (75,000+ visits)
- The Seven Core Practices of Agile Work (25,000+ visits)
- Eight Barriers to Effective Listening (17,000+ visits)
- Seven Essential Teamwork Skills (17,000+ visits)
- 24 Common Scrum Pitfalls Summarized (15,000+ visits)
- Mentoring and Coaching: What is the Difference? (14,000+ visits)
- Wideband Delphi Estimation Technique (14,000+ visits)
- The Pros and Cons of Short Iterations (13,000+ visits)
- Three Concepts of Value Stream Mapping (13,000+ visits)
- Agile Work and the PMBoK Definition of Project (11,000+ visits)
Ten Most Commented Upon Agile Advice Articles
- 24 Common Scrum Pitfalls Summarized (19 comments)
- Agile Becomes Easier with Useful Tools (12 comments)
- Important Words about Scrum and Tools (9 comments)
- The Skills Matrix and Performance Evaluation on Agile Teams (9 comments)
- The Definition of Done is Badly Named (8 comments)
- How Two Hours Can Waste Two Weeks (7 comments)
- Agile is Not Communism (7 comments)
- Agile Tools vs. Agile Books (6 comments)
- The Decline and Fall of Agile and How Scrum Makes it Hurt More (5 comments)
- The Planning Game: an Estimation Method for Agile Teams (5 comments)
I also want to acknowledge that there are a number of other contributors to Agile Advice besides me (Mishkin). These contributors are all experts, all have great experiences, and all are fantastic people to know. I’m grateful for their contributions since they have all made Agile Advice a better place to browse!
Five Most Frequent Contributors (of Articles, besides Mishkin)
- Paul Heidema (34 articles)
- Travis Birch (24 articles)
- Christian Gruber (19 articles)
- Mike Caspar (16 articles)
- Shabnam Tashakour (13 articles)
Plans for the Future – Five Top Ideas for Series
- Essays on each of the Values and Principles of the Agile Manifesto
- Summary articles of several Agile methods including Scrum, OpenAgile, Kanban, Crystal, XP, and others
- Real Agility Program case studies
- Reviews of other scaling / enterprise Agile frameworks such as Disciplined Agile Delivery, Large Scale Scrum, Enterprise Scrum
- New guest articles from thought and practice leaders.
The Doctor: Am I a good man?
Clara: I don't know. But I think you try to be and I think that's probably the point.
The Doctor: I think you're probably an amazing teacher.This year, I have my second full year as a Certified Scrum Trainer behind me. Looking back, it seems the first thing that happened after becoming was a CST was getting a steady stream of requests from aspiring CSTs to co-train with them. I held off the requests until this year. I have now worked with four aspiring trainers. In each case, I learned a lot and have come to appreciate both the value and the limitations of the mentoring system. I want to create a workshop for aspiring Scrum Trainers, so that they can rapidly achieve the level of a good CST.
What does a good trainer do?In my eyes, the purpose of a Scrum Master course is not to teach people the basic mechanics of Scrum. You can learn that from a 10 or 12 page document. The purpose is to enable the participants to discover a new, better, and more fun way of working, and leave them inspired to take that vision back to their companies to make it a reality! And they should have enough hands-on experience to have confidence and enthusiasm while getting started.
Just as Morpheus could only lead Neo to the door, but Neo had to choose to pass through, the job of a Scrum Trainer is to offer people that red pill. If what they learn resonates with them, they will want to plunge down that rabbit hole and explore it for a long time to come!
How do you train that? I believe that being a good trainer is a mixture of passion, attitude, skills and experience.
PassionIf there is one thing that can't be taught, it is passion. On the other hand, passion is contagious. So I try to give participants the opportunity to feel my passion and understand why I am passionate about Scrum. I believe sharing stories and learning by doing are the only way. As a Scrum Trainer, you need to be able to tell inspiring stories and facilitate great experiences.AttitudeIf you teach inspect-and-adapt, you have to do inspect-and-adapt, otherwise it is not authentic. (And sooner or later, you won't be very good, compared to others who do.)
I thought I was a pretty good trainer when I started. (Actually, I thought I was a very good trainer when I applied, which probably slowed my application tremendously.) Shortly after I started teaching certified courses, I noticed my Net Promoter Scores were not what I thought they should be. I also realized that despite collecting feedback from participants since my first course, I had never actually implemented a suggestion based on that feedback!
I wasn't inspecting and adapting, so I resolved to start. Since that moment, I read all the feedback. After each course, I strive to implement at least one suggestion or address one issue in the next course. I also send a follow-up to my participants with a summary of their feedback, and if possible, tell them what I plan to do differently in the future thanks to their feedback.
A funny thing happened. After an initial and substantial improvement, it got harder to improve. In some cases, I even regressed. But I didn't stop, even as I suffered some low points. Some issues were really hard to solve. I knew what the problem was, but didn't know how to solve them, even as I heard, time after time, that I needed to do something about it.
My willingness to adapt actually made it easier for me to change when the time was ripe. By always looking at how my customers were dissatisfied, I knew what needed to be done. Sometimes it took a while, but when I saw the solution to my challenges, I was able to implement them right away! (Thank you to the trainers and co-trainers I have worked with this year: Lizzie, Hugo, Elena, Niranjan and Andreas. Each of you has helped me move forward in important ways.)
The jump in my Net Promoter Scores was immediate and has been sustainable. I don't know if that qualifies me as a good trainer, but I am certainly better than I was two years ago, and it is the inspect-and-adapt cycle of Scrum which enabled me to get here.
How would I summarize the right attitude? A willingness to inspect, adapt and collaborate. How could you train that? Again, I think learning by doing and experiencing a-ha moments is the way to go.
Skills and experienceWhat else does a top trainer need to know? I believe a CST-level Scrum Trainer should...
- embrace the Agile Mindset
- have a validated deep understanding of Scrum
- have a validated understanding of what is not Scrum
- know how to teach so people learn.
- be able to teach any relevant topic spontaneously without powerpoint
- be able to tell authentic stories about their own experience doing Scrum to illustrate key points
- understand related approaches, e.g. Kanban, Radical Management, Lean Software Development, Extreme Programming, and how they relate to Scrum
- understand effective approaches for change leadership, e.g. Leadership Storytelling, Working Agreements, and how they relate to Scrum
- understand current vs. deprecated Scrum and agile practices
- be able to work with very large groups effectively
- Have I captured the right vision for a good trainer? What's missing? What's excessive? What's just wrong? Please leave a comment!
- Is there interest from aspiring Scrum Trainers for such a training? Do you know anyone who would be interested in attending some kind of workshop (webinar? combination?) to become a better Scrum Trainer or have an easier time with the TAC? If so, please share this article with them and invite them to start the conversation on my contact form.
Thanks to Tim Ottinger for reminding me of Arlo Belshee’s post, “Is Pair Programming for Me?” Go read Arlo’s post, as it’s insightful and has more useful content than most articles on pairing. I’m just going to springboard off of one skill that Arlo mentioned being important to learn.
How to avoid “paragraphing” when talking. Learning to speak in half-sentences, leaving room for the other to take the idea in an unexpected direction.
A few years back, I took a course in “Beginning Improv Acting.” I don’t plan to make a living performing improv theater, but I thought it would be beneficial for becoming more comfortable and competent at public speaking. It did that, but it also taught me some deeper lessons about collaboration, some so deep I can’t yet articulate them.
When performing improv, the flow on the scene might go in any direction, but it definitely won’t go the direction that you have in mind. No one else can see what’s in your mind, and they’re not working off your script. If you try to constrain them to your script, the scene quickly comes to a halt. In the class, we had one student who frequently caused this, and, while I learned how destructive this behavior is to collaboration, I also learned to avoid doing scenes with her whenever possible without being disruptive.
Instead, a big key to successful improv is to provide the other person with as many options as you can. You want to be detailed and concrete with your contribution to the scene, but without requiring a lot of baggage that hasn’t yet been made explicit. I found it helpful to avoid thinking too far ahead, as I would get attached to my story line instead of our story line. By providing options to the other people in the scene, I was also providing options for my future self. And I was encouraging them to maximize the options they provided me. The resulting explosion of possibilities made every improv response much easier and more natural. It was a lot of fun when we achieved that level of flow.
Pair programming with test driven development is, for me, exactly like that. When I’m pairing with someone who wants the code to go in a particular way, or when I want it to go in a particular way, it breaks the flow. Sometimes having a short design discussion leads us to agree on that particular way, and that usually works out OK. But the best pairing is when neither of us looks too far ahead, but writes the immediate concrete specifics of the moment. We trade frequently and excitedly, going in the direction that seems obvious. We achieve flow as a pair, and move quickly toward our functional goal.
Perhaps not everyone can work this way. Some people claim that they can’t work in a pair. I suspect that, more likely, they and/or their pair just haven’t developed the skill, yet. And you can only develop this skill by trying, and by practicing.
There’s a quote attributed to an anonymous Navy seal – a special forces unit in the U.S. Navy:
Under pressure, you don’t rise to the occasion, you sink to the level of your training. That’s why we train so hard.
As much as we might want to think that this only applies to life and death situations, I don’t think it does. In my experience as a software developer, a food-service worker, a construction worker, and even as a musician, I have continuously found this to be true.
There’s two major parts to this quote. The first of which says we don’t rise to the occasion. That part is a bit depressing on it’s own. But when we see the second part of this quote – that we train hard – we see some opportunity and some light at the end of the tunnel.When The Going Gets Tough…
In the first part of this saying, we fallback to the training, the habits and the “get it done” mode of work – no matter what that work is – when we face difficulties. It’s human nature to revert to a level of comfort and familiarity when faced with difficulties and challenges – especially when faced with life and death situations, but also when faced with deadlines at work and pressure to get things done.
Stress causes us to revert to previous ways that we are more familiar with, rather than the newer and better ways that we have been learning. There is less risk in the old ways. There is less discomfort and unease, which we need when we have other pressures put on us already.
This is not a bad thing. It is completely natural, and it is ok. Don’t look at your unwillingness to try that new framework or code technique as a sign of weakness or being lazy or anything else. See it for what it is: a need to get back to something more comfortable so that we can deal with the pressure that we are already facing.
But it can be a bit depressing to think that the work we want to do, knowing that there is a better way, is not the work that we will do when we are under pressure. Fortunately, the solution to this is also found within the same quote.We Can Do Better Under Pressure, If …
The secret to doing better when we are under pressure is to train when we are not under pressure.
When we have the luxury of stepping back for a moment and trying something new, we should. When we have more time than we need to implement that feature, we can take the time to practice something better. When we are specifically looking at time for training and practice, we can improve our abilities by making these new and better techniques more comfortable.
Training, while we are not under pressure, is the key to doing better when we are under pressure. The training that we do creates new habits, new levels of comfort, and new abilities.
Without training, we won’t be able to build new skills. But at the same time, we can’t expect to do any serious training while we are looking at deadlines and other pressures.What Kind Of Training? When?
The most important question here, is when. Getting training too early – long before you would ever use the tools or techniques learned – means you will likely lose those skills before you need them. Getting training too late is just as bad. You don’t want to spend time mastering a technology for a project that is already complete. Rather, you want to find training for your current tools / technologies / frameworks / techniques first. If you’re already in deep end, getting that training now can be a huge benefit. Next, look for training that will benefit an upcoming project you will work on.
The type of training largely depends on your learning style. Books, screencasts, classroom style, one-on-one q&a – these are all valid types of initial training. But initial training only goes so far. You need continuous practice-oriented training in order to cement the skills that you are attempting to acquire.How Much Training?
Once the initial training happens, you need to continue to exercise your new skills. You need to continue the training. Build sample projects. Find places where that new tool or technique can be put in to an existing project without causing delays or other difficulties. Spend a few hours a week continuing to do research and your own self-paced or mentored training.
Looking back at the quote above, there is a question you can ask that will help you determine whether or not you have had enough training: are you falling back to this tool / technique, when the pressure is on, as a place of comfort and familiarity?
Remember, you sink to the level of your training when you’re under pressure. If you find yourself sinking below the tools / techniques that you are attempting to acquire, when under pressure, then your training has been inadequate. But if you find yourself using these new tools and techniques with comfort and ease, while under pressure, then your training is solid. That doesn’t mean you’re done learning, but it does at least mean that you have acquired enough of a skill set to become comfortable with the tools and techniques that you set out to learn.Continuous Improvement
There will always be something new to learn, something to master, something to improve. You will always need to practice, to train, to ensure that the skills you need are so ingrained in your habits, that you can do the work without thinking about it. This is ultimately the type of training that you need – the type that is ground in to you so hard, and so well, that you can do it half asleep, while under life and death pressure, with others counting on you.
So get out there, get the training that you need and practice those new skills and tools until you can’t help but see the solution to the current problem, in the context of that training.
How big should your team be? Well it depends on what your most important goal is:
- If you are trying to keep costs down, a team size of 3 people or less is optimal.
- If you are trying to get a result as quickly as possible, a team size of 5 to 7 people is optimal.
- If you are trying to hit a budget or deadline as accurately as possible, again a team size of 5 to 7 people is optimal.
- If you are trying to burn a large budget, team sizes of 9 and up are best. These effects appear to be exponential.
I think this data explains the Guidewire approach of keeping teams between 3 and 6 people. In effect, this has them cycling between lowest cost and fastest delivery, which is probably a sweet spot to find yourself in.
OTOH - This study is largely based on waterfall projects. Does anyone have the data to create a similar study of agile projects?