I’ve written a couple of posts over the last few months about my experiences with A/B testing and one conversation we often used to have was around user experience vs conversion rate.

Once you start running an A/B test it encourages you to focus more on the conversion rate of users in different parts of the flow and your inclination is to make changes that increase that conversion rate.

Another one of our drivers is to provide the best user experience that we can to our customers and since sometimes this means that the best thing for them is not to switch it seems that these two must be in conflict.

I found it particularly interesting seeing how the conversion rate could be impacted by the way that information was displayed to a user.

This was an idea that I first came across when reading about how the Obama campaign used A/B testing where they noticed big changes in conversion rates by making small tweaks to sentences and imagery.

Our goal from a user experience perspective was to put all the information in front of the user so that they could make an informed choice about what to do.

Initially we made the negative features of the plans very prominent and had them in a large font which led to a drop in conversion.

We assumed that people were now giving more importance to the negative features than was warranted e.g. some plans had a cancellation fee but it typically only accounted for 5% of the saving they’d make by switching to the plan.

When the product is a bit more complicated we could argue that we improve the user experience by helping the user to make an appropriate choice.

On a website the way that we do this is by how we display information by changing the font size, font weight, positioning and a variety of other things.

It’s an interesting balance to find between the two drivers but if we veer towards conversion at all costs then although we’ll get a higher conversion rate in the long term we’ll have some frustrated customers who won’t use our website again.

If we look at it that way then the two drivers don’t seem so opposed to each other.

In a class, we had a large group of people from one company.  And the company is doing or getting close to doing mostly Scrum.

But the managers and the Board have not been to a Scrum class.

In any case, ‘management’ is still asking the Teams to try to deliver too much in too little time. And say both the scope and the date are inflexible. Or at least, that is how it is heard.

What is the solution?

This is one of the hard problems of our work.  There is no easy answer.

I think it boils down to this.

1. Customers want things quickly. And time itself has a value.  For example, we must get to market with our new product before the competition.

2. On the other hand, as they said in Latin some 2,000 years ago, to predict is difficult, particularly of the future.

So, we (the Scrum Team) must make predictions, and try to make them real.  AND, we must get everyone to understand all the changes that will happen. And all the variability in our ‘predictions’.  When we think the next release will be done and how much will be in it.

These are not easy conversations. Usually. People mis-understand each other.  Nonetheless, you must have the conversation.

Sometimes we say: we have a fixed time, a fixed scope and a fixed budget.

But always this is never completely true (in my experience).  There is always some proposed small features or featurettes in the work that do not have to be done in the current release.  This gives us an incentive to break down the features smaller, so we can identify small things to move to ‘later’.

Always there is a value to delivering fast. Usually, even before the current ‘date’ would be real good. Often very very good. (Which gives us yet more reason to reduce the number of small features in the release.)

And usually cost is NOT the main driver. There is (or should be) a huge ration between benefit and cost, so that being stingy about cost is silly. Especially when time is so important.

Lastly, in this too brief discussion, we must mention impediments. In Scrum, we want the Team to identify their biggest impediments.  Things that, if we fixed them, we could double (again) our velocity. Not by magic, not by working harder, but by fixing impediments. In the wetware, in the random carbon units, in the automated testing, in the management culture, whatever.  And often fixing impediments costs serious money.  So, we need good judgment to spend wisely.

Finally, we need to use Agile Release Planning to start to identify a reasonable scope and date, initially.  And, as things change (and everything will change at least some), we can revise and revise and revise it, and do the best we can to innovate in the time boxes we ultimately decide to give ourselves.

***

Managers must learn that if they pressure the Team (to deliver more in a given time), the Team usually hears two things: (a) cut quality, and (b) work high overtime.  So, the Team and managers (or customers) must talk about this.

Almost always the managers do not want reduce quality or overtime (bad quality of life). What they want is ‘creativity’.  Someone to cleverly see a simpler way to do things. How to remove an impediment. How to do fewer features. Something. Something unexpected that we might not have imagined without a challenge.

So, talk about this. Start to understand each other better. You need each other.

Hi,

I’ll be giving a talk on SAFe this Tuesday night at the Beyond Agile Meetup in Seattle.

Hope to see you there.

Hi,

Rob Pinna and I go way (and I mean way, way) back. I was interesed to see his perspective on the Scaled Agile Framework that he just published in a recent blog post. I thought he did a pretty good job of summarizing, but you can judge for yourself here.

 

Hi,

Rob Pinna and I go way (and I mean way, way) back. I was interesed to see his perspective on the Scaled Agile Framework that he just published in a recent blog post. I thought he did a pretty good job of summarizing, but you can judge for yourself here.

 

I’ve been noodling on the phrase “Thinking Together”. Thinking Together is one aspect of the mindset that Product Owners need to embrace. I have been using this phrase with new Product Owners to explain why many Agile practices work. But each time I start to write about this simple idea, it gets complicated because I get into process steps and roles and responsibilities.

Yesterday, I returned to a big company with a pretty complex product portfolio where we had done quite a bit of work including starting up multiple Scrum teams. I recalled our first release planning with this group. There was a lot of uncertainty and even some anxiety about this “lightweight” approach.

They were missing their requirements and specification documentation. They were hesitant to assess the value and size of the features, concerned they might leave something out. I prepared a Release Planning agenda for them to follow. I also prepared a list of roles and responsibilities. And I had some one page cheat sheets on the activities for release planning. They needed some process rules initially to learn how to think together.

When I ran into a Product Owner from this big company months later, the changes they had made were obvious. He was facilitating release planning and was excited to walk me through it.

My friend the product owner brought me into the conference room where they were wrapping up their release planning. There were some product managers, the product owner, some tech leads, QA and even a project manager. They were taking a break chatting and smiling. There were some architectural sketches on the white board. There were four flip chart sheets with sticky notes representing epics and features. The flip chart sheets represented the work completed for the past release, the plan agreed to for the next release, and planning for the following release. They had one more sheet with parking lot items.

The product owner showed me the result of their Thinking Together. They had discussed the epics written on blue stickies and wrote all the features they might need on purple stickies and put them under the epic. Then they thought together some more and rated each feature with business value, complexity and sizing. They added some acceptance criteria and clarified assumptions as they went. They did this for several epics. Then they started adding features to the flip chart sheet representing the next several releases.

Now, they realized they would not get everything done that the product managers wanted. So they moved some lower value features to the parking lot and rearranged the features on the flip chart sheets until they agreed on a plan. By Thinking Together in planning the next couple releases, they pretty quickly learned together and gained a shared understanding of the work they would do for the next six months.

They had learned to Think Together to get the end result: a solid release plan.

 

 

 

The post Thinking Together for Release Planning appeared first on LeadingAgile.

By Kevin Meyer

My Net Nonsense post from a couple weeks ago on the evils of large companies trying to force long payment terms on suppliers received considerable coverage, including being reposted in Quality Digest this week.  However the best - and funniest - commentary was by the editors of Quality Digest in their Quality Digest Live video.

For ten minutes, beginning at about the 13:20 point, they savage some well-known companies like DuPont, Procter & Gamble, Kimberly Clark, JC Penney, and more.  Check out their review of the hypocrisy of the mission statements of these companies.  Ha!  No kidding.  Actually rather sad.

Enjoy!

Question from a former Class Attendee:

Another question, this time about ranking user stories.
In the recent Scrum Master course, you indicated we should rank stories in the PB (Product Backlog) by Business Value and then do them from the top down. In the Product Owner course back in 2011, you had us calculate R = BVP / SP to arrive at the cost / benefit value and then rank by R. This would have the effect of doing longer items ahead of shorter items that have somewhat less business value.
What do you recommend now? What are your current thoughts?

Reply:

I explain this at a decent length in my small book on Agile Release Planning.

I am still a fan of the R factor.  AKA cost benefit analysis.

And a fan of making stories small.  To me, all epics eventually must be broken down so that we can get 8 items (stories) in a sprint.  So, if we have a velocity of 20 for a 2 week sprint, then items average about 2.5 story points in the sprint.

So, as stories rise to the top and get broken down, we have to re-point (both BVP and SP). And thus the R and the ordering will change.

Not quite sure what your concern is, but I think that resolves it.

The order can never be ‘purely’ business value.  We have other things to consider (which we might also call business value, but to me it gets too complex to put it that way….).  Things like Risks, Dependencies, Learning, MMFS (minimum marketable feature set), and Other factors.

So, I like to use R factor. Rank by that. And then have the Team discuss changes to that ordering.

Remember that to me the most important thing is that the Team together see the same elephant.

In the long term (or short term??) the PO wants to maximize the business value delivered out of the Team.  I think.  As a contrasting example, the PO is not optimizing the ‘efficiency’ of the Team (that each hour is used ‘productivity’).

Help?

Contiuous Delivery, Continuous Delivery, Continuous Delivery

That is all people are talking about these days. Well, me too. It's also what all the best development shops are moving to now. Well, me too.  

I participated in over a year long journey to bring Assembla into the Continuous Delivery world, and as any Continuous Delivery Afficionado would tell you, we continue to improve upon what we have learned.  After all, that is the basis of Continuous Delivery, improving upon what you learn in real-time.  As a matter of fact, it's the Key to Success with Continuous Delivery.

If I had to tell you one thing to do right now to start towards Continuous Delivery, it would be Production Monitoring. Useful for all systems, Production Monitoring is critical to your Continuous Delivery System, it allows you to react in real-time and gives you confidence to continue on.

Wednesday May 22: 1800 UTC, 1400 EDT, 1100 PDT

Assembla and Airbrake will present a Webinar: Production Monitoring: The Key Step Towards Continuous Delivery to help answer questions about Continuous Delivery and Production Monitoring.

In this webinar, we will discuss:

• What is Continuous Delivery, and how can it produce faster feature releases, improved quality and higher customer satisfaction?
• How do Continuous Delivery and production monitoring fit together?
• How can you collect and use error data and feedback effectively?
• Can Continuous Delivery with production monitoring actually decrease developers' stress levels and increase stability?

Register Now For Free 

 

To Learn more about Continuous Delivery, try these Blog Articles:

Continuous Delivery vs Continuous Deployment vs Continuous Integration - Wait huh? 

Which Git Workflow is Best? Mine of Course. 

 

 

 

 

      Traditional Estimation FunnelMicrosoft Story Point accuracy
Story points give more accurate estimates, they drastically reduce planning time, they more accurately predict release dates, and they help teams improve performance. Hours give worse estimates, introduce large amounts of waste into the system, handicap the Product Owner's release planning, and confuse the team about what process improvements really worked.

Interesting new research has become available. The Standish Group has updated their findings on project success rates based on analysis of the last decade of data with tens of thousands of data points. In addition, Microsoft has new research findings showing that agile estimation is astoundingly more accurate than traditional project estimation. See:

Scrum + Engineering Practices:  Experiences of Three Microsoft Teams
Laurie Williams, Gabe Brown, Adam Meltzer, Nachiappan Nagappan
IEEE Best Industry Paper award winner

Many people who have managed projects with hours have a hard time understanding why story points are better. They have failed to understand some fundamental data that has been published for over 60 years in the industry literature as well as the latest research.

First, let's look at the latest data on project failures. Failure rates are increasing for IT projects during the current disruption of the global financial system. The latest Standish group analysis shows that agile projects have three times the success rate of traditional projects. Jim Johnson now recommends agile practice be used universally on all projects.


In fact the latest Forrester Group research shows that:
Common Project Management Metrics Doom IT Departments to Failure

The venture capitalists I work with say they have never seen a correct GANTT chart in a board meeting. When they dig down into the problem they say none of their management teams knew the velocity of their teams before they implemented Scrum. Not knowing the velocity of production of the teams is the root cause of 100% failure of release plans to be accurate in their board meetings.

The stability of a user story is critical for planning. A three point story today is three points next year and is a measurable part of the product release for a Product Owner. The hours to do a story depend on who is doing it and what day that person is doing it. This changes every day. The GANTT chart assumes a fixed number of hours for some fictitious person (who often is not the person to implement) and assumes fixed dependencies (which are always changing). A study of 80 multimillion dollar projects at GSI Commerce (now owned by eBay) showed that the best experts in the company were totally incapable of estimating how much time a project would take by the people who actually implemented it.

You would think these data would cause people to change their behavior but many companies seem to prefer to continue to fail and be acquired or go bankrupt rather than improve their project management techniques.

Rand Corporation research in the 1940's showed clearly that humans are not good at estimating hours and practical experience repeatedly confirms the research. The recommended the Delphi approach to estimation which was adopted in software development as the Wide Band Delphi technique. The same technique is now embedded in the practice called Planning Poker for agile teams.

The management metric for project delivery needs to be a unit of production. Production is the precondition to revenue and companies say they are in business to grow revenue and margins (even though in project planning they often do the opposite). At least a venture capital group is clear that it is all about the money and money comes from velocity of production combined with quality of the product. Hours are expense and should be reduced or eliminated whenever possible.

The best data on individual developer performance comes from Yale University and has been reported previously on this blog. The best developer on a project takes one hour to complete a task while the worst developer takes 10 hours (within a project) or 25 hours (across projects). For teams the difference is an order of magnitude greater. Larry Putnam's published data show that an hour for the most productive team turns into 2000 hours for the least productive team.

Hours completed tell the Product Owner nothing about how many features he can ship and when he can ship them.

The important metric is the number of story points the team can deliver per unit of calendar time. The points per sprint is the velocity. Therefore we estimate everything in points for the Product Owner so that he create a release roadmap based on team velocity and adjust the plan if velocity changes.

The way we do story point estimation gives better estimates than hourly estimates as they are more accurate and have less variation. A CMMI Level 5 company determined that story point estimation cuts estimation time by 80% allowing teams to do more estimation and tracking than a typical waterfall team. A telecom company noticed that estimated story points with planning poker was 48 times faster than waterfall estimation practices in the company and gave as good or better estimates.

Story points are therefore faster, better, and cheaper than hours and the highest performing teams completely abandon any hourly estimation as they view it as waste that just slows them down.

For a complete break down on the points vs. hours debate see Scrum Inc.'s webinar on the topic. 

It’s fairly hard to know what solid testing is all about within Agile and Scrum teams. What traditional practices are fine to continue, which ones need modification and what totally new approaches are necessary. Moving from traditional to agile testing is often a high-wire balancing act to some degree with no clear direction. This video presents the critical lessons from teams that have successfully made the transition. We’ll explore the requisite team skills, how to deal with agile requirements, the right strategies for developing agile automation, how to plan and test ...

We are now over 1000 new accounts further since we’ve released tinyPM 3.0 BETA. Since that time we were working hard on different aspects of a new version of our agile tool. I would like to summarize those efforts and tell you a bit more about the nearest future of tinyPM.

What we did?

First of all we committed a first sin of software development and decided to rewrite tinyPM from scratch :-) Yes – we did it! And what is more important we do not regret that!

So what it exactly means? We’ve moved from JBoss Seam + JSF + RichFaces + Prototype and Scriptaculous stack to Grails + jQuery + Twitter Bootstrap. Why should you care? Well – you don’t need to, but this means that we can finally do what we really want to do in terms of UI/UX solutions, which was very limited with previous technology. This also means that we will be able to better and faster improve tinyPM for you.

Finally this means that the new tinyPM 3.0 is made to best support its new SaaS environment. You can now just sign up in a few seconds and start using tinyPM. You can upgrade or downgrade your plan at any time. We switched technology here too!

New tinyPM no longer uses PayPal which is so troublesome! We’re now using Braintree Payments solution which is light years from PayPal in terms of integration simplicity and usability. But this is probably another story which I will tell you one day if you are interested :-)

New tinyPM version incudes also quite a lot of small changes in the tool itself. This affected language versions, but YOU proved once again to be a great community! It took about a month to get tinyPM back to be translated into 8 languages including German, French, Spanish, Chinese and Russian. Thank you one more time!

What we are working on right now?

We started with SaaS solution, but it doesn’t mean that we’re abandoning the on-site/downloadable version of tinyPM. We are finishing it right now, so it will be available soon. Everyone that is already using tinyPM 2.x will be able to migrate to the new version and of course all the licenses will still work!

Moving from v2.x to v3.0 will be done through migration of projects and wiki in the same way as you can do it right now to move from on-site to SaaS solution (some of you already did that). This means that you will be able to install v3.0 as a separate instance, move selected projects (also leaving behind those that you finished long ago) and test the effects without affecting your current instance.

We are also finishing the timesheet functionality allowing you to record time spent on tasks on a daily basis. This function along with the small fixes and improvements in tinyPM will get us to the final v3.0. So we’re leaving the BETA mode really soon. We actually made new tinyPM 3.0 use a new production environment a while ago, so the BETA is just a name add-on, but now you will know for sure!

What’s next?

Of course we will continue to improve tinyPM as we did for a few years already. We always try to adapt tinyPM to your needs. A few things ahead are:

• Customizable dashboard and metrics – we will dig through the data tinyPM collects and will give you as many details as possible, so that you can choose which matter to you and so that you can put them on your own personal dashboard
• Integrations – when you decide to use a SaaS tool, it’s probably because you already got used to a SaaS environment. We will make tinyPM fit better to that environment so that you can use data from your other tools to drive your development in tinyPM.
• API/imports/exports – we cannot even imagine in how many ways you are analyzing your portfolios, processes and actions. That’s why we will give you back all the data you may need, so that you can always take them with you and report them your way.

We will be posting some more information about those areas here on tinyPM blog. We will also ask you for feedback, so stay tuned!

Continuing with the 100 Things You Must Know to Be Effective In Software Development The purpose of development/IT is to deliver value quickly - not just for a team, but for the entire organization. If you reflect on this, it's not about going fast, it's about removing delays.  Delays are typically waiting for folks, getting feedback late, detecting errors late, or just going to work on...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]

The needs to go faster to market and cut costs, dominating the industry lately, are significantly changing the landscape of software quality. Many pillars of successful quality strategies in the past are just slowing down delivery too much. We will have to find better ways to provide build in quality into our systems, track and [...]

Partnership & Possibilities – Episode 4, Season 3

Partnership & Possibilities: A Podcast on Leadership in Organizations
EPISODE 4: THE STAR

“In a team situation, having a star performer becomes a threat and an opportunity. If a person is a star performer, their job is to spread their skills around to other members, to mentor and pair with people so other people’s skills are lifted up to where theirs are.”

Running time 40:50

Have you encountered a star performer in your organization? Was it a positive experience? How did your organization respond to the star performer?

Leave a comment on this blog or email us at leadershippodcast@gmail.com

Summary
Intro – Brief overview of a case study from the Harvard Business Review: the unmanageable star performer. How does an organization leverage a star performer for the benefit of all?
8:40 – Acknowledge the star performer’s achievement and introduce new opportunities to them to become even better.
13:05 – An organization should prepare itself for the potential exit of a star performer. There should be a succession plan in place to mitigate risks.
21:21 – Having a star performer can be a threat and an opportunity.
30:05 – Beyond generating revenue, star performers can possess rare skill sets that are in high demand and which can make the person indispensable.
38:37 – Star performers can enhance their standing in the organization and increase the knowledge base by sharing their skill set with others in the organization.

Resources
Case Study: The Unmanageable Star Performer, Harvard Business Review

Photo Credit: mj*laflaca via Compfight cc

Each Sprint that a Scrum Team does is an opportunity for learning through “inspect and adapt”.  If there is a break or a pause between Sprints, the Scrum Team may forget what it has learned or fail to apply that learning in a timely manner in the next Sprint.  Of course, many Scrum Teams end a Sprint before a weekend and start their next Sprint at the beginning of the next week.  This non-working break is normal and acceptable.  However, a break between Sprints during which some or all Scrum Team Members do other work is not acceptable.

Kennt ihr ihn auch? Den ausgepowerten Product Owner, der vor lauter Terminen seinen Tag doppelt bis dreifach verplant hat? Oder den eifrigen ScrumMaster, der noch abends im leeren Teamraum sitzt und die Retro für den nächsten Tag akribisch vorbereitet? Manche sagen dann: “Das kann nicht gut sein.” Und zitieren das Agile Manifest, das von “nachhaltiger Entwicklung” und von einem “gleichmäßigen Tempo” erzählt, das “auf unbegrenzte Zeit” haltbar sein soll. Häufig geistert dann noch dieses eine Wort herum: Burnout.

Ja, der gute Product Owner hat eine ganze Menge zu tun: Er soll möglichst nah an seinem Team sein, mit dem Kunden im ständigen Kontakt stehen, und darüber hinaus die gestalterische Gewalt über das Produkt haben. Für manchen klassischen Projektleiter bedeutet das ein deutliches Mehr an Aufgaben und an Verantwortung. Auch der ScrumMaster ist, wenn er für sein Team da sein und Scrum in die Organisation tragen soll, gut ausgelastet.

Am Ende eines langen Tages stellt sich dann der Frust über die vielen Stunden ein, die man wieder mit Meetings und Abstimmungen verbracht hat. Spannenderweise beziehen sich die Klagen, die mir zu Ohren kommen, fast immer auf die Quantität. Dabei scheint es eine fest verankerte Vorstellung von “Normalität” zu geben: Der Achtstundentag gilt als das gesunde Maß aller Dinge. Neun Stunden werden noch toleriert, zehn gelten vielerorts schon als grenzwertig – und bei allem, was darüber liegt, erntet man besorgte Blicke und gilt als ernstzunehmender Burnout-Kandidat.

Tomas Chamorro-Premuzic hat im Harvard Business Review einen wunderbar provokanten Text geschrieben, der genau diese Korrelation zwischen Dauer und Last in Frage stellt. Seine Behauptung: Überarbeitung ist nur dann möglich, wenn du keinen Spaß bei der Arbeit hast (http://blogs.hbr.org/cs/2013/02/embrace_work-life_imbalan.html):

“Work is just like a relationship: Spending one week on a job you hate is as dreadful as spending a week with a person you don’t like. But when you find the right job, or the right person, no amount of time is enough. Do what you love and you will love what you do, which will also make you love working harder and longer. And if you don’t love what you are doing right now, you should try something else — it is never too late for a career change.”

Nehmen wir das Zitat ernst, sollten wir am Ende eines langen Tages Rückschau halten und für uns prüfen: Was habe ich heute alles gemacht? Was davon hat mir Spaß gemacht, was hat mich herausgefordert, wo ist die Zeit schnell vergangen? Und wo habe ich mich herumgequält, wo war es einfach nur mühsam und frustrierend? Am Ende eines ganztägigen Trainings bin ich manchmal so kaputt, dass ich kaum noch aufräumen und packen kann. Und trotzdem schwebe ich einen halben Zentimeter über dem Boden, halb euphorisiert und halb benommen von den vielen Eindrücken und Erlebnissen des Tages. Die Belastung eines solchen Tages ist enorm, aber sie macht mich nicht fertig. Es ist dann wie ein langer, langer Lauf, an dessen Ende man glücklich auf dem Rasen sitzt und keuchend grinst.

Wenn wir mit Scrum erreichen möchten, dass Menschen anders miteinander arbeiten und daran wachsen, dann können wir nicht einfach weitermachen. Wir müssen uns vielmehr überlegen, was von der bisherigen Arbeitsweise noch Sinn macht, und was komplett gestrichen werden muss.

Drei Vorschläge:

• Meetings auf maximal dreißig Minuten reduzieren und dadurch auf das wirklich Wichtige begrenzen. Eine gut vorbereitete Agenda, ein Moderator (der nur moderiert) und strenge Einhaltung der Timebox.
• In der Mitte des Meetings einen Energizer einbauen (ein kurzes Bewegungsspiel oder etwas mit Humor). So kommt einem die Zeit nur halb so lang vor, eine andere Hirnregion wird aktiviert, man kommt auf andere Gedanken und das Schwere wird etwas leichter.
• Meetings komplett abschaffen. Stattdessen ein Daily zur Synchronisation und dann Open Spaces: Jeder, der ein Anliegen hat, wirbt im Daily dafür, nennt Zeit und Ort. Und jeder, der mit dabei sein möchte, gesellt sich dann einfach dazu. Klingt radikal, ist aber einfach nur eine Umkehrung der Verhältnisse: Wer zuvor über einen “zugemüllten” Terminkalender geklagt hat, der ihm noch den letzten Atemraum genommen hat, darf nun den Luxus eines unbeschriebenen Blatts genießen, das er selber gestalten darf, indem er sich die Themen für den Tag aussucht. Auch das ist mehr Verantwortung, aber es macht den Getriebenen wieder zum Handelnden. Und das kann dazu führen, dass der Job wieder Spaß macht und die Zeit wie im Flug vergeht.

Tomas Chamorro-Premuzic: Embrace Work-Life Imbalance. HBR Blog Network. http://blogs.hbr.org/cs/2013/02/embrace_work-life_imbalan.html

Principles behind the Agile Manifesto: http://agilemanifesto.org/principles.html

Related posts:

1. Der ScrumMaster als Dienstleister
2. Volles Scrum ist gefragt!
3. Sie können abschalten, wir haben die Vision

30 Days of Getting Results is a hard-core time management course.   

It’s a 30 Day Sprint with a lesson each day, but you can go at your own pace.   For example, I every now and then I scan through it in about 20 minutes to remind myself of the best time management skills to work on.

Some of you have let me know that you can’t get to the site.   I’m not sure why.  

Regardless, I have a free PDF version of 30 Days of Getting Results available.

It’s powerful stuff.   If you want to master time management, productivity, and work-life balance, this short-course will help you do that.

Time management and extreme productivity are a few of the things that I regularly mentor individuals, teams, and leaders on.

It’s 129 pages, and very easy to flip through.

Each lessons includes an exercise to make it real and drive it home.

If you download and go through it, please rate it on Good Reads.

Enjoy.