In the Kanban Coaching Professional Masterclass, I teach coaches and those leading Kanban initiatives how to assess the appropriateness of the Kanban Method and the appropriateness of applying a kanban system within an organization. This is the first of a series of blog posts on appropriateness and getting started with an enterprise scale Kanban initiative.
I was asked the other day, “Do you use Scrum at home?” It’s not the first time that I’ve been asked this question. The honest answer is: no. Oh, I’ve used bits and pieces here and there. I’ve put together a taskboard to track work on the occasional big household project. I’ve even built a backlog from time to time. But that is about the extent of it. I’ve been married for nearly twenty years – I’m not about to screw it up with Scrum or any other method for that matter.
You won’t find me standing around with the kids doing a daily standup. There is no weekly planning meeting on my family calendar. And the only retrospective that I do is after getting caught leaving the toilet seat up (“Doh!”). Nope, I’ve got to be honest, my household isn’t very agile.
You might ask, “Why not?”
Dang, that’s a really good question. I’m not sure that I have a good answer. Maybe I just want to leave all that stuff at work. But if that were the case, then why do I go home and write this blog? No, that’s not it. Maybe there really has been no structure modelled in my family life before. In fact, the very idea of doing that kind of “work” at home makes me cringe a little bit. I guess I feel like we have things under control. Maybe I don’t even want that control. It’s really hard to say.
I think there is value in sharing the practical time management techniques that I use at work with my kids. I didn’t hesitate to introduce them to pomodoros when my daughter was struggling to stay focused on her homework. It felt really good to be able to introduce her to a tool that would help her be successful. She loves pomodoros! The kids like all the fooling around that I do with self-experiments around the house (“Hey! Look at Daddy!”). They always want to know what kind of nutty thing Dad is doing this week.
However, I’ve never felt a compelling need to have any kind of formal family meeting at all. Call me a bit waterfall. I guess when it comes to my family I only want to give them the techniques that they need for the problems they have. I don’t want to burden them with a framework. Got a problem with focus? Use pomodoros. Does the problem seem too large? Break it down into stories. No progress? Try iterating.
When I can provide a helpful technique that solves their problems (agile or not), I feel like Superman. Seriously folks, there is no better feeling in the world. There is no preaching. I don’t lecture them on the perils of waterfall. To my kids a waterfall is something you ride a log down at Disneyland. I aim to keep it that way as long as possible.
I guess, in retrospect it’s not such a bad approach for introducing agile practices for anyone, regardless of whether they are in your family or not. In fact, why would you treat a team any differently than your family? Aren’t they just that – your extended family? Can we use this to inform how we approach introducing Agile Practices to our teams?
Maybe we just introduce them to the tools they need to solve the problem that they have in the moment. Perhaps that’s how we start. That’s how we demonstrate value and earn trust. Not by dumping some framework they must comply with on their heads.
Hmmm….I think I’ve been doing it wrong.
Introduce agile practices to your team like you would to your family. Give them only what they need and let them figure out the rest.
Filed under: Agile, Coaching, Teams Tagged: Agile, family, practices, Scrum
Knowing your Myers-Briggs type is almost as common as knowing your credit score – maybe even more so. It’s widely considered to be the most frequently used personality test, but evidence – or, rather, lack thereof – suggests that it’s totally meaningless and organizations should stop using it.
CEOs get paid too much, according to pretty much everyone in the world. But how much do you think they actually get paid, versus should get paid? Recent research says that, globally, we’re very naive about the actual disparity between what we think is fair and what they collect.
How much time do you spend in front of an electronic screen every day? Your computer at work, tablet to read on the bus, TV in the evening, phone to just quickly check email or peek in on Facebook… It all adds up, to about 6 or 7 hours a day if you’re average. It’s tough to be bored with so many things to occupy our every free moment. But being bored is important to being creative and productive.
Children are taught about nutrition and exercise for their bodies, but what about keeping their brain fit and healthy? Barbara Arrowsmith Young, author of “The Woman Who Changed Her Brain,” makes the point that every kid should practice stress reduction and targeted cognitive exercises at school, and it applies just as much to adults too.
An employee review is supposed to help identify issues and increase employee performance, ultimately increasing productivity for the company. But a study found that companies that use 360 reviews, where colleagues and clients provide the feedback, saw a 10% drop in performance.
Setting goals for agile projects is trickier that setting goals for waterfall projects. As I mentioned in an earlier letter, for waterfall projects it is possible to set the goal in the form of a feature list to be delivered. This approach has several drawbacks - it does not guide the thousands of micro-decisions that are made, it gives no sense of purpose to support the drive or inner motivation, and it gives no guidance for evaluating whether the money, time, and effort was well spent.
However, although all these problems, and although the approach is not advisable - it is still possible. The project management mindset and tools for waterfall projects are applicable for reporting project status or following up visavi a feature list. It is also possible to evaluate success by checking whether everything on the feature list is implemented.
Well, I still think it would be better to evaluate whether the project created some value.
Now, ridiculous as this seems it is still industry standard.
The CHAOS report 1995 from Standish Group might be one of the most cited reports in system development. According to its statistics only 16% of software projects succeed. In the 2012 report this has been updated to 39%. And they collect data from tens of thousands of projects so the figures should be pretty reliable.
Now, this seems scary and low, but only until you check out their definition of success."Resolution Type 1, or project success: The project is completed on-time and on-budget, with all features and functions as initially specified."OK. Not a word about actually getting value for the effort. Remember the on-line bookstore where they wanted others-have-bought recommendations to increase the number of books customers. Now, imagine they implemented the others-have-bought recommendations, but the customers did not buy more books anyway. Is this project a success?
Well, you have spent lots of money building something, but made no money from it. To me it sounds like money, time, and effort down the drain - not as a success.
To Standish Group, it is considered a success.
On the flip side, imagine the project realising that a simplified "search similar" would increase the number of books each customer buys. Imagine further that this feature would be much easier to implement. So, the project decides to implement that feature instead. And the number of books sold per customer increases 0.4 on average.
Spending less money, time, and effort on something else than originally envisioned, but still getting the benefit - that sounds like success to me.
To Standish Group, it is considered a failure.
Thus, the figure 16% or 39% actually says nothing at all about the state of software projects.
So, Standish Group is probably filled with smart people. Why did they not evaluate software projects according to some meaningful metric instead? Most probably "generated business value as specified upon funding" would be more interesting.
My guess is that too few projects actually stated an envisioned business effect, so analysing those projects would give so little data that it would not be possible to make any significant conclusions.
So, instead of measuring something that would actually matter ("fulfilled envisioned business effect") they just measured something that could be measured.
Now, from the second example, where the team implemented another feature than originally envisioned, it is also clear that this approach is an absolutely worthless way of evaluating agile projects.
PS The CHAOS 1995 report has been republished openly available for academic purposes. It can be found at http://www.projectsmart.co.uk/docs/chaos-report.pdf. The 2013 version can be found at http://www.versionone.com/assets/img/files/CHAOSManifesto2013.pdf
Among the great things I learned last week in London UK at the Scaled Agile Framework (SAFe) Program Consultant training is the concept of using the Weighted Shortest Job First method of prioritization for backlog items. The concept is similar to the Relative Return On Investment (RROI) that I teach in my Certified ScrumMaster and Certified Scrum Product Owner courses, but adds a bit of sophistication both in the background theory and in the actual application.
Weighted Shortest Job First is a numerical score where the larger the score, the sooner the job (feature, product backlog item) should be done. Scores therefore give a sequence to jobs. The score is based on the ratio between two estimates: the estimate of the “cost of delay” and the estimate of the “duration to complete”. The cost of delay is a more sophisticated version of business value in that it takes into account customer needs, time criticality and risk reduction or opportunity cost.
In SAFe, the WSJF is calculated at the level of the team’s backlog on user stories through estimates of effort by the team and estimates of the cost of delay that are done by the product owner in collaboration with program management and business owners. The effort estimate is considered a reasonable proxy for the measure of duration, but there is explicit acknowledgement that this may not always be a reliable relationship.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!
Old habits die hard. When a developer suddenly steps into the Tech Lead role, it is not immediately clear what to do differently. Instead of taking on the Tech Lead responsibilities, they stay heads-down writing code. The more code they write, the better they feel that they are still contributing to the team. Other Tech Lead responsibilities are neglected in favour of writing code, even though they must still be fulfilled. A Tech Lead must spend enough time on non-coding responsibilities. They must ensure a Technical Vision exists, and the development team are working together towards the same goal. Both of these activities require more than just code-writing.2. Not spending enough time writing code
The “Tech” in the Tech Lead role is there for a reason. It is too easy for a Tech Lead to sit in endless meetings instead of spending time with the team. They lose awareness of how the code is evolving and which patterns or anti-patterns emerge. Without an up-to-date awareness of the system and its technical constraints, a Tech Lead cannot effectively lead the team. A Tech Lead who codes has a better understanding of technical problems or opportunities whilst building and maintaining trust with developers. Writing code keeps the “Post Technical” label away.3. Making all the technical decisions
The first time Tech Lead may feel compelled to make all decisions. To compensate for writing less code, or to demonstrate their new role, they give input to any and all decisions. Unfortunately this behaviour discourages the team from making contributions. It sends the message to the team they should do what they are told, or not think, even though a team member has the better solution to a particular problem. An effective Tech Lead knows when to give input, knows when to make decisions and when to step back and allow the team to take more ownership.4. Talking only Tech
A Tech Lead interacts with many people who sit outside of the development team such as people from marketing, finance or a product division. These people usually have very limited technical knowledge. Talking to them in terms of frameworks, libraries and tools adds confusion, frustration and simultaneously signals a lack of empathy. A Tech Lead must find a way to communicate ideas in ways non-technical people can understand such as using analogies and using terms others can easily relate to.5. Constantly reacting
A new Tech Lead will find themselves juggling several activities at once. The bane of a developer, interruptions, becomes an everyday occurrence. A first time Tech Lead can simply react to the loudest or most alarming situation, even if it is not the most important. Over time, the Tech Lead develops better time and task management skills in order to manage the many demands.
If you liked this article exploring the Tech Lead role, you will be interested in “Talking with Tech Leads,” a book that shares real life experiences from over 35 Tech Leads around the world. Now available on Leanpub.
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
As some of you may know, I’m building a boat in my brother’s garage. We had a big milestone the other day: we finished painting the bottom and rolled the boat over to finish the topsides. From a distance it looks great!
Up close is another story though. Up close you can find ripples in the paint from where the fiberglass wasn’t sufficiently well sanded. There are other places where you can see fine lines in the paint due to underlying patterns in the filler compound. Add to that the fact that the paint has rough areas where the roller left a pattern. And don’t even get me started about that flat spot.
I see all of these imperfections and more. It’s pretty rough.
I’ve worked with teams like that too. From a distance, everything looks great. You are hitting your milestones and everyone is pleased.
But get close and you find all sorts of flaws. They’re not using story points. They won’t keep their burn down chart up to date. They don’t even know what an acceptance test is. They’re pretty rough. Maybe we should just keep them in the garage…
But around this time, along comes my brother. He takes one look at the boat and says, “Damn! That’s beautiful!” So I point out a flaw. He waves it off and says, “The only boat without scrapes and dents is in the showroom. This boat is going to sail!” Not to be dissuaded, I point out another flaw. He looks at me and says, “Will it float?”
My answer, “Yes.”
“OK then. Let’s get this thing in the water.”
And so we go back to work, and somehow it is OK. I stop worrying and focus on what remains to be done.
Sometimes someone visits the office. Someone I really respect and admire. I show them around and they say, “Wow, what a great team!” So I walk them over to the story board and point out that it’s out of date. They look at me and say, “That’s cool. Not many people even use physical dashboards.” I tell them that the team doesn’t use story points. They look at me and say, “Does the team deliver?”
My answer, “Yes.”
“OK then. Let’s sling some code.”
And so I’m reminded not to be such a damn perfectionist.
Love your boat.
Love your team.
Filed under: Agile, Coaching, Teams Tagged: perfection, Teams
An vielen Ecken hört man es: die “Generation Y” will anders arbeiten. Die jungen, gut ausgebildeten Menschen zwischen 20 und 30 wollen einfach nicht mehr so hart rackern wie die Generation vor ihnen, heißt es. Und andererseits wissen die Vertreter der “Generation Me” (auch als Baby Boomer bezeichnet) nicht, wie sie im Job mit dieser Generation umgehen sollen. Nähern wir uns dem Thema Work-Life-Balance mit der Brille der “Generation Me”, dann verfällt man schnell der Idee, dass es neben der Arbeit noch etwas anderes geben sollte. Neben der Arbeit. Mich hat diese Trennung von Arbeit und Freitzeit immer gewundert. So als hätte man zwei Leben, als könne man jede Minute zweimal ausgeben: privat und beruflich.Generation Me: erfolgreich krank
Woher kommt das Bedürfnis bei Menschen der Generation, der auch ich angehöre, nach dieser Work-Life-Balance? Vielleicht weil wir den Wohlstand, das zweite und das dritte Auto, damit erkauft haben. Wir haben sehr viel und sehr hart gearbeitet, denn harte Arbeit ist unser Statussymbol. Gleichzeitig haben wir nicht nur finanzielle Erfolge und Wohlstand erarbeitet: viele von uns haben sich im wahrsten Sinne des Wortes krank gearbeitet. Ich gebe es zu, auch ich bin bei zwei bis vier Flügen pro Woche und durch das ständige Schlafen in Hotels nicht so fit und gesund, wie ich es sein könnte. Auch die Zeitungen und Magazine sind voll von Berichten über unsere schwer erarbeiteten Zivilisationskrankheiten. Wäre ich, so wie viele andere, auch mit 30 Vater geworden, wäre meine Tochter oder mein Sohn jetzt schon 15 und würde sich zu Recht fragen, ob dieses Kaputtarbeiten irgendeinen Sinn hat und ob er oder sie das will. Ihre Antwort wäre natürlich: “Nein!” Und die Vertreter der Generation Y haben natürlich recht, sie müssen es auch gar nicht mehr.Langweilige Paradiese
Ihre Eltern haben in vielen Unternehmen bereits die vollkommenen Paradiese geschaffen. Dort sind die Arbeitszeiten festgezogen, alles ist geregelt und wer freiwillig mehr leisten will, wird schief angeschaut (natürlich gilt das nicht in jedem Unternehmen). Gleichzeitig wird die Alterspyramide die Gehälter steigen lassen. Bei einer momentanen Geburtenrate von 1,34 in Österreich und der Tatsache, dass die Baby Boomer allmählich in Massen in Rente gehen, wächst der Wert der Arbeitskraft ins Gigantische.
Gleichzeitig sind die großen Betriebe so durchgestylt, dass die Folge nur noch verwöhnte Langeweile sein kann. Wieso ich das sage?
Ein Beispiel: Ich hatte einen Bewerber zum Interviewtermin, der aus der Automobilwirtschaft kommt. Heute 30 Jahre alt, Doktor der Soziologie, entscheidet er sich bewusst gegen die 35-Stunden-Arbeitswoche in einem großen deutschen Automobilkonzern. Die Arbeit dort ist nicht etwa zu anstrengend, sondern zu langweilig. Dort sind die Arbeitsabläufe geklärt, die Projektmanager verbringen ihre Zeit in stundenlangen Meetings, in denen doch nichts Wesentliches passiert, und der Effekt, also ihr Beitrag, ist gleich Null. Die Arbeit wird in Großunternehmen bzw. -konzernen sowieso von Dienstleistern erledigt – wie es Putzerfische bei einem Wal tun. Etwas bewegen, Sinn stiften und sich beweisen, dabei vielleicht auch scheitern und lernen, ist in diesen Unternehmen schwer geworden.
Doch schauen wir mal dorthin, wo die eigentlichen Veränderungen derzeit passieren – nein, nicht bei Goolge und Co. Ganz ehrlich, eine Übermutter als Arbeitgeber, die mit ständig verfügbarem Essen, Massage und 1000 anderen Annehmlichkeiten aufwartet, wo Geld keine Rolle spielt und man machen kann, was man will, erzeugt kein Umfeld, in dem Innovation aufkommen kann. Der Spieltrieb wird angefacht, sicher, und es ist bestimmt ultracool, bei Google zu arbeiten. Aber mal ehrlich, welche Innovationen kamen von Google? Eine einzige! Ihre geniale Suche. Alles andere ist nachgebaut und bestenfalls optimiert. Google geht gerade den Weg der meisten großen Unternehmen: die Kreativität ist dahin, man beginnt, die Konkurrenz und die neuen Ideen zuzukaufen, statt selbst tolle Dinge zu machen.Neuer Realismus in der Arbeitswelt
Wo ist also das Neue für die Arbeitswelt? Es beginnt immer am Rand. Da ist etwas Neues zu beobachten. Wahrscheinlich werden jetzt viele Trendforscher sagen: “alter Kaffee”, aber ich nehme gerade etwas vollkommen Neues wahr. Kleine Firmen, die weltweit verteilt sind und dank neuer Kommunikations- und Arbeitsinfrastrukturen wie Google Hangout, Skype und GitHub Bedingungen geschaffen haben, mit denen man als kleines Team weltweit miteinander arbeiten kann, beginnen tatsächlich ganz anders zu arbeiten.
Da erzählen dann diese merkwürdigen Menschen aus der Generation Y, dass sie zuhause in ihren Wohnzimmern oder kleinen Arbeitszimmern sitzen, und gleichzeitig bei ihrer Familie sein können (Beispiele für diese Firmen sind: WordPress.com oder Bufferapp). Die Firmenmitglieder treffen sich ab und zu, um sich auch mal zu sehen, aber die Arbeit wird remote, verteilt und dezentralisiert gesteuert. Es entstehen dabei sogar neue Taskmanagement-Systeme, die tatsächlich ein neues Konzept verfolgen: IDoneThis. Sie zeigen, was gelungen ist, und nicht das, was man hätte tun sollen. Das ist eines der ersten Systeme, das mit einer vollkommen anderen Sicht entwickelt wurde. Hier ist es nicht vorgesehen, jemand anderem zu sagen, was er zu tun hat. Jeder sagt – offen – etwas darüber, was er getan hat. Ziemlich verrückt aus der Sicht der Generation ME. Work-Life-Balance spielt für die Generation Y keine Rolle mehr. Sie haben schon lange einen Weg gefunden, freier und viel realistischer mit ihrem Leben umzugehen.
In response to the POODLE SSL vulnerability, we have removed SSL v3.0 support from Tracker.
For the most part, this should not affect Tracker customers using the recent browsers we support. However, there may be some scripts, 3rd party tools or integrations using SSL v3.0 to access our API, in which case those will break.
Update: 10/17/2017: The following is corrected. For customers using our JIRA integration, with a hosted JIRA instance, Atlassian has also removed SSL v3.0 support from all of their Cloud platforms. Our integration with them isn’t currently working as a result, and we’ll correct that as soon as we can.
If you have questions or do run into any problems, please email to let us know.
It’s hard to drive digital initiatives and business transformation if you can’t create the business case. Stakeholder want to know what their investment is supposed to get them
One of the simplest ways to think about business cases is to think in terms of stakeholders, benefits, KPIs, costs, and risks over time frames.
While that’s the basic frame, there’s a bit of art and science when it comes to building effective business cases, especially when it involves transformational change.
Lucky for us, in the book, Leading Digital: Turning Technology into Business Transformation, George Westerman, Didier Bonnet, and Andrew McAfee, share some of their lessons learned in building better business cases for digital initiatives.
What I like about their guidance is that it matches my experienceLink Operational Changes to Tangible Business Benefits
The more you can link your roadmap to benefits that people care about and can measure, the better off you are.
Via Leading Digital:
“You need initiative-based business cases that establish a clear link from the operational changes in your roadmap to tangible business benefits. You will need to involve employees on the front lines to help validate how operational changes will contribute to strategic goals.”Work Out the Costs, the Benefits, and the Timing of Return
On a good note, the same building blocks that apply to any business case, apply to digital initiatives.
Via Leading Digital:
“The basic building blocks of a business case for digital initiatives are the same as for any business case. Your team needs to work out the costs, the benefits, and the timing of the return. But digital transformation is still uncharted territory. The cost side of the equation is easier, but benefits can be difficult to quantify, even when, intuitively, they seem crystal clear.”Start with What You Know
Building a business case is an art and a science. To avoid getting lost in analysis paralysis, start with what you know.
Via Leading Digital:
“Building a business case for digital initiatives is both an art an a science. With so many unknowns, you'll need to take a pragmatic approach to investments in light of what you know and what you don't know.
Start with what you know, where you have most of the information you need to support a robust cost-benefit analysis. A few lessons learned from our Digital Masters can be useful.”Don’t Build Your Business Case as a Series of Technology Investments
If you only consider the technology part of the story, you’ll miss the bigger picture. Digital initiatives involves organizational change management as well as process change. A digital initiative is really a change in terms of people, process, and technology, and adoption is a big deal.
Via Leading Digital:
“Don't build your business case as a series of technology investments. You will miss a big part of the costs. Cost the adoption efforts--digital skill building, organizational change, communication, and training--as well as the deployment of the technology. You won't realize the full benefits--or possibly any benefits--without them.”Frame the Benefits in Terms of Business Outcomes
If you don’t work backwards from the end-in-mind, you might not get there. You need clarity on the business outcomes so that you can chunk up the right path to get there, while flowing continuous value along the way.
Via Leading Digital:
“Frame the benefits in terms of the business outcomes you want to reach. These outcomes can be the achievement of goals or the fixing of problems--that is, outcomes that drive more customer value, higher revenue, or a better cost position. Then define the tangible business impact and work backward into the levers and metrics that will indicate what 'good' looks like. For instance, if one of your investments is supposed to increase digital customer engagement, your outcome might be increasing engagement-to-sales conversation. Then work back into the main metrics that drive this outcome, for example, visits, like inquiries, ratings, reorders, and the like.
When the business impact5 of an initiative is not totally clear, look at companies that have already made similar investments. Your technology vendors can also be a rich, if somewhat biased, source of business cases for some digital investments.”Run Small Pilots, Evaluate Results, and Refine Your Approach
To reduce risk, start with pilots to live and learn. This will help you make informed decisions as part of your business case development.
Via Leading Digital:
“But, whatever you do, some digital investment cases will be trickier to justify, be they investments in emerging technologies or cutting-edge practices. For example, what is the value of gamifying your brand's social communities? For these types of investment opportunities, experiment with a test-and-learn approach. State your measures of success, run small pilots, evaluate results, and refine your approach. Several useful tools and methods exist, such as hypothesis-driven experiments with control groups, or A/B testing. The successes (and failures) of small experiments can then become the benefits rationale to invest at greater scale. Whatever the method, use an analytical approach; the quality of your estimated return depends on it.
Translating your vision into strategic goals and building an actionable roadmap is the firs step in focusing your investment. It will galvanize the organization into action. But if you needed to be an architect to develop your vision, you need to be a plumber to develop your roadmap. Be prepared to get your hands dirty.”
While practice makes perfect, business cases aren’t about perfect. Their job is to help you get the right investment from stakeholders so you can work on the right things, at the right time, to make the right impact.You Might Also Like
Cesar Abeid interviewed me, Project Management for You with Johanna Rothman. We talked about my tools for project management, whether you are managing a project for yourself or managing projects for others.
We talked about how to use timeboxes in the large and small, project charters, influence, servant leadership, a whole ton of topics.
I hope you listen. Also, check out Cesar’s kickstarter campaign, Project Management for You.
The SAFe SPC training last week taught me quite a few interesting and useful new things. In reviewing my class materials, I noticed this little acronym: ROAM. The way it is used in the SAFe training is that it is a mechanism for categorizing risks that teams identify as they are doing release planning. ROAM stands for Resolved, Owned, Accepted, Mitigated. The members of an Agile team or Agile Release Train identify risks and collaborate to decide how to handle them. These risks are then place on a visible grid that has each of the four categories marked. In this way, the whole Agile Release Train and their various stakeholders can have an open discussion and shared understanding about the risks to the Program Increment that they are planning. Cool!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!
We have already had User Story as most popular tool. But this is not the end. Today about Iterations: the small and big ones, these that are completed and those that are never stopped.
Iteration is a period of 1 to 4 weeks. During this time Customer needs to decide what is the most important at this moment. 4 weeks is also called the Sprint but we prefer Iteration as it’s stronger option.
Iteration is not only about programming but also about tests and more. Actually tests are run before the programming phase.
We also have to mention about infinite period. In this case Iteration is one, only User Story has to be completed in some period of time and then disappears. In this place another User Story appears. Customer tells about that User Story and if it’s good we start with the new one.
And what do you think about this?
Coaching can make the difference between an organisation’s success or failure. In this month’s blog, Peter Hundermark outlines why effective coaching allows companies to admit their weaknesses and move towards a happier and more effective workplace. Read the full article here.Kanban Training We have FOUR seats remaining on the upcoming Applying Kanban (Foundation) course taking place on the 20-21 Oct 2014 in Sandton. Be sure to book your place before these are snapped up. Should these dates not work for you, we will be running the course again on the 04-05 May 2015.
We also still have a few spaces available on our upcoming Improving & Scaling Kanban (Advanced) course which will be taking place in Sandton on the 23-24 Oct 2014. We are running a 3-for-2 special offer on both the certified Foundation and Advanced courses, so be sure to secure your place!
InfoQ have published the remaining two articles in the series from the short book “Leading Self-Organising Teams” written by Dr. Sigi Kaltenecker & Peter Hundermark. Have a read of these articles: “why do we need self-organising teams?” and “what is Leading Self-Organising Teams all about?”
Q&A TeleconferencesEsther Derby is offering free Q&A teleconferencing sessions. Each month Esther chooses a topic which will be of interest to people who coach, manage, or work on software teams. Follow this link to sign up. Upcoming Courses Applying Kanban (Foundation) – (JHB) – Only 4 seats left!
20-21 Oct 2014
FNB Conference & Learning Centre, Sandton
Improving & Scaling Kanban (Advanced) – (JHB)
23-24 Oct 2014
FNB Conference & Learning Centre, Sandton
Certified Scrum Product Owner (JHB) – Fully booked!
04 – 05 Nov 2014
FNB Conference & Learning Centre, Sandton
Certified Scrum Master (JHB)
01-02 Dec 2014
FNB Conference & Learning Centre, Sandton
Course schedule and Book Online
I’m a little down on the notion of continuous improvement these days. It’s not that it doesn’t happen – it does…sometimes. I simply fear that it promises too much. I think part of it is the terminology. You see in the real world continuous improvement is neither truly continuous or necessarily an improvement.
To begin with, I’ve critiqued the notion of continuously improving before from the point of view that keeping any process happening full time is ludicrous. Certainly once every sprint is nowhere near continuous. I guess maybe it is continuous when you compare it to other more plan driven methods, but that’s far from continuous in my book.
No, the part that I find most objectionable is the improving part. You see, it’s misleading. It suggests to me that every change is an improvement. That every effort is a step forward, not back. And that is simply not how it works. It would be better labelled periodic experimentation, or punctuated mutation. You see, in the real world, when we change something, we never really know if it’s going to work out or not. There are 50/50 odds that the change will actually make things worse!
Of course that’s a good thing. We learn a little either way. Hopefully.
The problem I have with continuous improvement is that it sets up an unreasonable expectation in those we sell it to. To restate the sales pitch: every change will be an improvement and they happen all the time.
If every change were really an improvement, I would be worried that I had been transported to an alternative universe. That I was being monitored by aliens. That there was a black helicopter hovering over my house. I’d be making a tin foil bunny suit. Fortunately I know what universe I’m in, that there aren’t any black helicopters over my house, and tin foil tends to chafe in the damnedest places. Not too sure about the aliens…
Fortunately, many of my efforts at improvement fail. And that’s the way it should be.
Filed under: Agile, Process Tagged: continuous, evolution, experimentation, failure, improvement
We’ve been working diligently on continued conceptualization of the SAFe LSE Big Picture, as well as the new article content. To that end, we’ve just updated the Big Picture to rev 0.30. (yeah, 30 revs so far, see below).
In addition, we just announced the first training course for SAFe LSE. Leading SAFe LSE is a three-day course, the first of which which will be offered in Boulder, February 3-5, 2015. Registration is now open here. Harry Koehnemann, Alex Yakyma and I will be teaching that course, so you can hear the new content “right from the horses” mouths.
With respect to the new framework, our current target is to publish the website as a work-in-process towards the end of this year (likely end of November), with a full release, including an exam and Certification process, later in 2015.