Skip to content

Feed aggregator

Agile Projects should have Effect Targets

Dear Junior

Measuring projects and setting targets for them is a tricky business. And, it does not get easier when agile projects enter the scene. This is not really because agile projects are strange per se, but because they are different from non-agile projects.

Setting targets and measuring projects is also an important business. I have seen several agile initiatives fail. Most of them have failed because they did not succeed in setting goals for projects, and monitor their progress. And if you cannot do that, you quickly lose the confidence and support from upper management. Agile initiative terminated, or left to dwindle away. End of story.

However, it need not to be so. Agile projects can have measurable targets, and they can be monitored - you just have to do it right.

There are some bad news and some good news.

The Well-Established Chaos Rod for Measuring Success

The bad news is that agile projects cannot be measured using the de-facto established standard rod for project success.

The standard rod for measuring projects is "on-time and on-budget, with all features and functions as initially specified", as used by e g Standish Group in their much-to-cited Chaos Reports. Let us call this the "Chaos rod". Most organisations use some version of the Chaos rod for measuring their projects.

As we have discussed earlier it is pretty obvious that "all features implemented" is not a good way to measure "project success" - not for any project. Nevertheless, this is the standard rod.

Damned if you do, damned if you don't

Of course agile projects will fail if measured using the Chaos rod. The reason is simple - agile projects does not manage to keep their hands away from fiddling with the original specification. Agile projects remove stuff, change stuff, add stuff - agile projects are in a constant state of scope-creep.

This is no coincidence - it is how agile projects are designed.

Think of it this way: If we learn something during the run of the project - shall we let that insight effect the plan of what we intended to do? Or shall we ignore that insight, sticking to the original plan even though inferior? Of course we will adapt! Anything else would be ridiculous.

An agile project anticipates that such insights will emerge, so its processes are designed to harness and leverage upon those insights: demos, retrospectives, re-prioritisation of product backlog etc. These practises are all aimed at constantly refine and redefine the scope. But then, we have derived from the original specification "all features and functions as initially specified".

Thus, any agile project longer than a sprint will fail - by definition. That is, if you use the Chaos rod for measuring success.

To put it bluntly, if you measure an agile project using the Chaos rod, it will fail. Either the agile process will fail, or the project as defined will fail.

Either, the project adapts to its measuring rod and blindly follows the "functions as specified", throwing whatever insight gained aside. Then, "project" will succeed, but "agile" will fail.

Or,  the project will work according to its agile-minded processes, and then certainly the result of the project will not be "all features and functions as initially specified". Then, "agile" will succeed, but "project" will fail. I e project will fail as measured by Chaos rod.

Damned if you do, damned if you don't.

A New (or Old) Hope

The good news is that the Chaos rod is not the only way to measure projects. As we have discussed earlier, there has always been two ways to measure projects: feature list (Chaos rod) or measuring business effect, what we can call the Effect rod.

Let us take our earlier example with an on-line book store. They had an idea that recommendations of the type others-have-bought would increase their sales, so they set of some money for that projects.

Using the Chaos rod they would have created a feature list around others-have-bought recommendations. The project would later be evaluated on how well it implemented the list. But let us look at a better idea.

Using the Effect rod they might set a target that customers will by 0.35 more books per checkout on average. The Effect rod is used to state the value of a project. These 0.35 books can probably be converted to money, that makes the project worth the effort.

The project might start out with an idea that others-have-bought recommendations would cut the cake. After the first small stories, deployed to production and put into hands of customers, the team learns that some kind of category would be helpful. To facilitate this they implement a simplified "search similar" as one of their features.

Suddenly the number of books in the checkout carts raise to a level 0.4 above the pre-project baseline. And the level sustains, it was not just random noise - the change is statistically significant.

The project has fulfilled its target according to the Effect rod, and is declared a success.

Measuring using the Chaos rod "on time, budget, and specification" - the project would have been deemed a failure, because it did not deliver the initially specified others-have-bought.

So, agile projects can be measured. You just have to use a measurement that is well suited. And, to be honest - which is better anyway.

A sad side-note is that I know of several projects which have worked in an agile manner, and delivered enormous business benefit - but in the project report the project lead has had to apologise repeatedly for not meeting the project target as defined in the project specification - a feature list.

Granted, to measure projects on business effect is not a new idea in any way at all. The idea was certainly there before the Agile Manifesto was written around the turn-of-millennia. What is new is that this way of measuring is essential to provide rigour to agile projects.

For Agile to succeed at larger scale, we certainly need lots practises around agile-minded processes. Measuring agile projects on effects is certainly one of them.

The way to measure agile projects is to set targets for business effect.

Yours

   Dan

PS Interesting enough, there is a sub-category "agile projects" in the later Chaos Reports, but the rate of success is not 0%, it is around 40%. I wonder what is going on here.

PPS Within the agile community, the practice of projects is debated - at least in the sense of the common description "temporary organisation with limited time, resources, and ambition". So, it would probably be better to use some other term, e g talking about "initiatives". However, for convenience, I have kept the often-used and familiar term "project". Check out the twitter hashtag #NoProjects.



Categories: Blogs

Synchronitis – eine unheilbare Krankheit?

Scrum 4 You - Wed, 11/12/2014 - 08:30

Ein Problem, das uns immer wieder begegnet, ist die Tendenz, mehrere Dinge zugleich zu machen. Man beginnt mit einer Sache und während man diese zu beenden versucht, wird einem der hohe Zeitdruck bewusst. Also beginnt man gleich mit der zweiten Sache.

Die dahinterstehende Logik ist eher nicht vorhanden, es scheint vielmehr eine natürliche Stressreaktion zu sein. Und seien wir mal ehrlich: Wer kennt sie nicht, die ellenlangen To-Do-Listen, und plötzlich schweift man vom aktuellen Thema ab, um mit dem nächsten zu beginnen. Dabei scheint man das erste Thema völlig zu vergessen und wenn es einem dann leider doch wieder einfällt, muss man plötzlich zwei Dinge parallel fertigstellen. Ist ja an sich kein Problem. In den letzten Jahren wurde uns viel über Multitasking erzählt und dass viele Menschen dazu fähig seien. Prinzipiell stimme ich dem zu. Multitasking ist möglich, man kann sich um zwei Dinge gleichzeitig kümmern. Man kann sich nur nicht so gut und gleich schnell um zwei Dinge kümmern wie um eines.

Wenn Sie glauben, zu den absoluten Ausnahmen zu gehören, dann empfehle ich den folgenden Test. Dafür brauchen Sie eine Stoppuhr, ein Blatt Papier, einen Stift und ca. 2- 3 Minuten Zeit.

  • Single-Task-Variante: Starten Sie die Stoppuhr und schreiben Sie die Zahlen von 1 – 26 durchgehend in eine Zeile, direkt anschließend das Alphabet von A-Z. Stoppen Sie die Uhr (und wenn Sie noch mehr über die Auswirkungen von Single-Tasking versus Multitasking lernen wollen, halten Sie auch kurz fest, wie sehr es Sie subjektiv angestrengt hat).
  • Multitasking-Variante: Starten Sie wieder die Stoppuhr, aber dieses Mal schreiben Sie abwechselnd eine Zahl und einen Buchstaben, also: 1 A B 2 C 3 usw. Stoppen Sie wieder Ihre Zeit (und notieren Sie, wie angestrengt Sie sich gefühlt haben).

Mein Ergebnis bei diesem Test war recht eindrucksvoll: Beim Multitasking war meine Leistung um ca. 25% schlechter. Außerdem fand ich die Multitasking-Variante wesentlich anstrengender als das Single-Tasking.
Ich empfehle, es wirklich auszuprobieren. Es kostet nicht viel Zeit und wird Sie hoffentlich von Synchronitis befreien. Es funktioniert einfach nicht, mehrere Aufgaben gleichzeitig gleich gut abzuschließen. Aber es funktioniert wunderbar, eine Aufgabe nach der anderen zu bewältigen – und es geht sogar schneller. Bei der Übung handelt es sich noch dazu um gut trainierte Aufgaben, die jeder von uns schon tausende Male ausgeführt hat. Je komplexer die Aufgaben sind, desto größer wird aber der Zeit- und Qualitätsverlust durch Multitasking, da wir uns in jede Aufgabe wieder neu eindenken müssen.

In diesem Sinne: Achten Sie auch bei Ihren Scrum-Teams darauf, dass Stories nach Möglichkeit einzeln abgearbeitet werden, statt parallel. Das Ergebnis wird dem Single-Tasking qualitativ und quantitativ recht geben.

mathematics-111423_1280

Related posts:

  1. Certification Test is Postponed
  2. Certified ScrumMaster – The Test
  3. Unit Testing, Test Driven Development

Categories: Blogs

XP Days Ukraine, Kiev, Ukraine, December 5-6 2014

Scrum Expert - Tue, 11/11/2014 - 20:03
XP Days Ukraine is a two-day conference dedicated to Agile engineering practices. Its aim is to provide practical skills and new ideas to Agile practitioners with the help of local and international Agile and Scrum experts. The presentations cover the main Agile engineering practices like TDD, Continuous Integration or BDD. Topics like Agile architecture, technical debt or communication between developers and testers are also discussed. In the agenda of XP Days Ukraine you can find topics like “Design and architecture in Agile project”, “Why testing take so much time?”, “Continuous Development ...
Categories: Communities

User Stories Splitting Patterns

Scrum Expert - Tue, 11/11/2014 - 19:54
When a Scrum team starts its sprint, it needs to have user stories with the right size so that they can be completely developed at the end of the iteration. The art of slicing larger stories and epics that exists in the backlog to right-sized item for a sprint is not easy. Richard Lawrence has done some work on this topic and has outlined 9 patterns for splitting user stories. He has produced a cheat sheet with example stories for each pattern. These patterns have also been summarized on a poster ...
Categories: Communities

Dealing with the linker in Xamarin apps

Jimmy Bogard - Tue, 11/11/2014 - 18:51

The last few months I’ve been working quite a bit with Xamarin and in particular Xamarin.Forms. I’ve got a series of posts upcoming on my exploits with that and migrating to ReactiveUI, but first things first, I actually need to deploy my app.

I’ve got my app working in debug/release mode in the simulator, and debug mode on a device. However, when I ran the app in release mode on a device, it just crashed without warning. Not a very good experience. I’ve deployed this app several times on the device, but something was causing this crash.

Typically a crash on a deployment is one of two things:

  • Something off in DEBUG conditional code/config
  • Something off in DEBUG/RELEASE project config

I checked the DEBUG conditional code config, which does things like point to the test/production API endpoints. That looked OK, so what else was different?

Screen Shot 2014-11-11 at 9.20.41 AM

That was my debug version of the app, where no assemblies were linked. In the Release mode, only SDK assemblies were linked. For many cases, this works, as the compiler can figure out exactly what methods/fields etc. are being referenced.

Normally, this is OK, until you get a series of telling exceptions, usually a MissingMethodException. In my case, I switched my Debug settings to the same as Release, and got:

System.MissingMethodException: Default constructor not found for type System.ComponentModel.ReferenceConverter
  at System.Activator.CreateInstance (System.Type type, Boolean nonPublic) [0x00094] in /Developer/MonoTouch/Source/mono/mcs/class/corlib/System/Activator.cs:326
  at System.Activator.CreateInstance (System.Type type) [0x00000] in /Developer/MonoTouch/Source/mono/mcs/class/corlib/System/Activator.cs:222
  at System.ComponentModel.TypeDescriptor.GetConverter (System.Type type) [0x0009f] in ///Library/Frameworks/Xamarin.iOS.framework/Versions/8.4.0.16/src/mono/mcs/class/System/System.ComponentModel/TypeDescriptor.cs:437
  at ReactiveUI.ComponentModelTypeConverter.<typeConverterCache>m__0 (System.Tuple`2 types, System.Object _) [0x0002d] in /Users/paul/code/reactiveui/ReactiveUI/ReactiveUI/Platform/ComponentModelTypeConverter.cs:24
  at Splat.MemoizingMRUCache`2[System.Tuple`2[System.Type,System.Type],System.ComponentModel.TypeConverter].Get (System.Tuple`2 key, System.Object context) [0x00000] in <filename unknown>:0
  at Splat.MemoizingMRUCache`2[System.Tuple`2[System.Type,System.Type],System.ComponentModel.TypeConverter].Get (System.Tuple`2 key) [0x00000] in <filename unknown>:0
  at ReactiveUI.ComponentModelTypeConverter.GetAffinityForObjects (System.Type fromType, System.Type toType) [0x00000] in /Users/paul/code/reactiveui/ReactiveUI/ReactiveUI/Platform/ComponentModelTypeConverter.cs:30
  at ReactiveUI.PropertyBinderImplementation+<typeConverterCache>c__AnonStorey5.<>m__0 (System.Tuple`2 acc, IBindingTypeConverter x) [0x00000] in /Users/paul/code/reactiveui/ReactiveUI/ReactiveUI/PropertyBinding.cs:1006
  at System.Linq.Enumerable.Aggregate[IBindingTypeConverter,Tuple`2] (IEnumerable`1 source, System.Tuple`2 seed, System.Func`3 func) [0x00000] in <filename unknown>:0

First lesson: keep linker settings the same between build configurations. When you encounter this sort of issue, the problem is usually the same – reflection/dynamic loading of assemblies means the linker can’t see that you’re going to access some type or member until runtime. The fix is relatively simple – force a reference to the types/members in question.

In my iOS project, I have a file called “LinkerPleaseInclude.cs”, and in it, I include all types/members referenced:

public class LinkerPleaseInclude
{
    public void Include()
    {
        var x = new System.ComponentModel.ReferenceConverter (typeof(void));
    }
}

Completely silly, but this reference allowed my app to run with the linker in play. More info on the linker can be found on the Xamarin documentation.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Categories: Blogs

SonarQube 4.5 in Screenshots

Sonar - Tue, 11/11/2014 - 18:18

The team is proud to announce the release of SonarQube 4.5, which includes many new features:

  • Computation of the SQALE Rating and the Technical Debt Ratio
  • Improvement to the Rules pages
  • Redesign of the Treemap

Computation of the SQALE Rating and Technical Debt ratio

With this version of the SonarQube platform, the SQALE Rating (letter grade) and Technical Debt Ratio move from the SQALE plugin into core. Now there’s an easy index for project comparison, and an easy way to see it too, the new “Technical Debt Synopsis” widget:

Improvement the the Rules pages

This version of the platform brings several improvements to the Rules space.

The first is the addition of a new Active Severity feature, which lets you search for rules by the severities they have in a given profile (rather than by default severity):

This version also makes the rule’s SQALE/Technical Debt remediation function visible. I.e. you can see now how much violating a rule will “cost” you in terms of technical debt. Just click on the SQALE characteristic to see it:

The ability to create new manual rules has also been added to the Rules space. Since markdown is now supported in rule descriptions, you can use it to add some formatting to manual rules:

Once created, you’ll find them in the “Manual Rules” repository:

Redesign of the Treemap

The treemap, one of the earliest visualizations of code in SonarQube got a complete overhaul in this version. Rewritten in JavaScript, you should find it more responsive, more intuitive, and just as beautiful as ever. Among the changes are a better mouseover, and a clickable breadcrumb trail at the bottom for zooming out:

That’s all, Folks!

Time now to download the new version and try it out. But don’t forget to read the installation or upgrade guide.

Categories: Open Source

How Leaders are Building Digital Skills

J.D. Meier's Blog - Tue, 11/11/2014 - 17:51

Cloud, mobile, social, and big data are changing the game of business.

But to play the game well, leaders need to grow new skills.

In order to create new customer experiences and market-leading operational capabilities, leaders need to invest in digital skills.

Our Cloud-First, Mobile-First world provides unprecedented possibilities in terms of connectivity and compute resources for changing customer experiences, transforming the workforce, and transforming operations, and creating new business models.   Companies every day are building amazing solutions that integrate Cloud, Mobile, Social, and Big Data capabilities as well as what the Internet of Things brings to the table.   But to take advantage of these capabilities, you need leaders that grow and invest in a digital platform and in digital skills.

In the book, Leading Digital: Turning Technology into Business Transformation, George Westerman, Didier Bonnet, and Andrew McAfee, share how top leaders grow their digital skills.

Creating Great Customer Experiences Requires New Skills and New Ways of Working

Whether you want to reimagine your customer experience, or reimagine your operations, it takes new skills, and new ways of working.   Companies that don’t have the right digital skills struggle.   Worse, everybody is competing for the same skills, including social media analysts, mobile marketers, cloud architects, and data scientists.

Via Leading Digital:

“Creating great customer experiences or market-leading operational capabilities is more than technology challenge.  It's also an organizational challenge requiring new skills and new ways of working.  Yet, 77 percent of companies in our first year of research cited missing digital skills as a major hurdle to their digital transformation success. To compound the problem, most companies are chasing after similar skills--social media analysts, mobile marketers, cloud architects, or data scientists, to name a few.”

How Digital Masters are Building Skills

If you want to help your company become a Digital Master, or, if you want to be a high-performing leader, you need to invest in digital skills.  

Via Leading Digital:

“So what are Digital Masters doing differently when it comes to skills? First, they are investing.  Of the Digital Masters we surveyed, 82 percent are building the digital skills they need to support transformation efforts.  Only 40 perce3nt of nonmasters are doing so.

Second, Digital Masters are accelerating and creating  a gap.  Our survey research shows that the masters had greater digital skills than nonmasters, reporting 31 percent higher social media skills, 38 percent higher mobile skills, and 19 percent higher analytics skills.

But Digital Masters did not start with higher skills.  Burberry did not become excellent at digital marketing. and channels overnight.  CEO Ahrendts hired a new, dynamic marketing team whose members mirrored the behaviors of the millennial customer.  Nor did Caesars excel at delivering personalized customer experience solely because its CEO, Gary Loveman, has a PhD in economics from MIT. Caesars' executives actively incorporated quantitative skills into the marketing area.  In these companies, like other Digital Masters, top executives worked hard to build the digital skills they needed.”

The Line Between Technical Skills and Leadership Skills is Blurring Fast

The gap is huge but the lines blur fast.  There is a huge demand for people that are both business savvy and technology savvy.

Via Leading Digital:

“The skills difference extends beyond technology.  Digital Masters report 36 percent higher skills in digital leadership than nonmasters. Digital transformation requires changes to processes and thinking--changes that span your internal organizational silos.  'The clear delineation between technical skills and leadership skills in blurring fast.

The impact of digital technologies is now felt not only in the IT and technical departments, but also across the entire organization.  Digital transformation's need for cross-functional collaboration creates a huge demand for hybrid digital skills-- technical people who need to be more business savvy and businesspeople who need to be more technology savvy.  A retail executive explained: 'We are trying for the first time to work across the company.  That implies going through a new level of complexity in the organization, and requires people to manage and network differently.  That, I think, is the most important skills that needs to be developed.'”

Successful Leaders Will Have Business and Technical Skills

True hybrid professionals will be the leaders of tomorrow.

Via Leading Digital:

“The need for new skills can also result from the need to bridge the communication gap between digital and business competences.  One executive said, 'I need a charismatic quant--somebody who's an influencer and can carry his weight in a senior meeting, but at the same time, someone who can roll up his sleeves and look at data tables and build models and enjoy it.'

These bridging roles may soon become the responsibility of every manager. 'I believe,' said Markus Nordlin, CIO of Zurich Insurance, 'that the successful leaders of tomorrow, in any business or industry, are going to be true hybrid professionals who have spent some time in IT but have shifted to operations and vice-versa.'”

Digital Skills Create Competitive Advantage and Enable Digital Transformation

To keep up and get ahead, you need to master Digital Skills and be able to use them in a business savvy way.

Via Leading Digital:

“Aspiring Digital Masters are all chasing the same technical skills.  The shortage of digital skills is unprecedented.  In Europe alone, forecasts point to nearly a million vacancies for IT-related roles by 2015.  And globally, out of the 4.4 million big-data jobs to be created by 2015, only a third will be filled.

But by the same token, business professionals will increasingly need to be comfortable with digital tools and technologies to perform their core roles.  By 2015, research firm IDC expects that 90 percent of all jobs will require IT skills.  Some business functions are already adding technology skills to their mix.  Gartner reports that 70 percent of the companies they surveyed have a chief marketing technologist to support the digitization of the function.

This skills race won't slow down anytime soon.  Having the right digital skills is an important source of competitive advantage and a key enabler of digital transformation.  Companies that build skills faster will get ahead.

To win at the digital skills race, you will need to tap into multiple approaches--hiring, partnering, incubating, and the like.  It's not easy, as one executive explained: 'Our recruiters don't know where to go to find these people, and people with the right skills don't look to our kind of company for opportunities.'  HR organization will need to get up to speed quickly.  A recent Capgemini Consulting survey found that only 30 percent of HR functions were actively involved in digital skills development.  This needs to change.  Many Digital Masters have a carefully crafted plan to fight and win the talent race.”

All of the capabilities of Cloud, Mobile, Social, and Big Data are right at your fingertips.

Using these capabilities in meaningful ways takes a combination of business and technical skills, as well as great organizational change leadership skills.

If you can master business skills and combine them with great technical skills, you can lead you, your team, your organization, and others to change the world.

You Might Also Like

10 High-Value Activities in the Enterprise

Cloud Changes the Game from Deployment to Adoption

Drive Business Transformation by Reenvisioning Operations

Drive Business Transformation by Reenvisioning Your Customer Experience

Dual-Speed IT Drives Business Transformation and Improves IT-Business Relationships

How To Improve the IT-Business Relationship

Management Innovation is at the Top of the Innovation Stack

Categories: Blogs

The neverending waveform of the full-stack developer

Xebia Blog - Tue, 11/11/2014 - 17:50

There was an article on Techcrunch a couple days ago which was linked in our internal mailing list the other day, titled The Rise And Fall Of The Full Stack Developer. I read it, and I just couldn't figure out why the title is about "the fall" of the full-stack developer (and I said as much on the mailing list, after which I was encouraged to write this blog post). In this post I'll try and explain why it's not the end, but just a stage in a recurring cycle

What I read was a waveform - the article describes that first you had low-level assembly, which is specialised but still pretty straightforward since it's just one platform and language. Then things started to get more complicated, with the larger web applications involving lots of experts in various fields (Java, database management, server and JVM management, to name a few from the article).

In or around 2005, there was a bit of a revolution going on. Internet access (and high-speed internet for that matter) became accessible to all, and with it, cheap webhosting - most notably, there was a boom in PHP development. What the article highlights is that that was an era where single or small teams of developers could build a web application from scratch, without needing to lug around all of that expert knowledge - effectively, a full-stack developer (storage, webhosting, a programming language (PHP, Python, Ruby, etc), HTML, CSS, Javascript, the whole stack).

But, as the article states, that isn't the full stack of today - added to that are things like machine learning, mobile development, more advanced and less traditional programming languages, frameworks and persistence solutions, etcetera. The conclusion of the author is that it's too much for one full-stack developer to take, that there's no way a full-stack developer can be an expert in all of those fields - and he basically renames the person that knows a bit of all of those technologies a full-stack integrator, and declares the full-stack developer dead.

But I didn't see that. What I saw was just history repeating - from simple and manageable, to complex and too much for one person to handle and know all about. From assembly and PHP, to Java enterprise software and Docker-contained AWS instances running a MongoDB and Scala REST interface to power your Android, iOS and single-page AngularJS-powered webapps (to name but a few buzzwords).

I'm sure the next 'simple' wave is already around the corner - maybe it's already here, lurking somewhere until some more influential guy goes "Hey guys, let's go back to the simpler, good old times where you wrote code and it Just Worked™!", where a wave of developer will follow - most likely a combination of younger people, new to the software development world, and older people that have been stuck in an overly complicated software development rut for far too long.

As for not being able to keep up with it all, this is why it's probably better to assemble teams out of T-shaped developers - full-stack developers with a broad knowledge set (and more importantly, broad interests and curiosity), but with at least one specialisation. This was extended within Xebia to pi-shaped developers, then made extreme to comb-shaped developers, but the latter is just a generalist like mentioned in the article - a jack of all trades, master of none. And it's important to realise, as a developer, that it's OK to not know everything, to miss some update, to not learn that fancy new programming language by people disgruntled by Java's slow development - there's simply too much information updates today, and trying to manage it all in the extremest forms can lead to serious problems. But the rapid development is a good thing, I might add, I don't think the software development world has ever moved as fast as it does today, and it's not nearly the end yet as long as more than half of the world's population doesn't have access to the internet and its boundless resources.

I think increasing complexity is just part of software development. I mean look at Facebook and Twitter - they were started using those simple, accessible tools like PHP and Ruby on Rails, which allowed them to get a flying start and adapt quickly to their huge growth (and with the former desperately clinging to their decision, despite lots of people telling them they should use a different technology), but despite that they still turned into some of the most complicated pieces of software ever. The important bit is to be able to manage all that, not so much a decision between a simple or complicated toolset - or having all of your developers know everything. Similarly, the current trend is microservices - again back to simple, one-purpose miniature applications that do one thing and do them right. But those will just end up being the next generation of huge, complicated software systems, given enough time. As a colleague stated, "Microservices are just hipster SOA".

As the saying goes, the more things change, the more they stay the same. The full-stack developer isn't dead and won't be going away any time soon, he'll just go by a different name depending on the times - J2EE Certified Software Engineer, full-stack developer, multidisciplinary expert, T-shaped developer, Xebian, chief of technology evangelisation, or whatever else the HR or marketing departments of the near future will come up with.

Categories: Companies

What Can Haruki Murakami Teach Us About Sustainable Pace?

Leading Agile - Mike Cottmeyer - Tue, 11/11/2014 - 17:39

sustainable pace

Sustainable pace is all about keeping positive energy flowing on your teams. It doesn’t mean taking it easy. It doesn’t mean struggling to achieve a constant pace. It means expending your energy in a positive way, on the right things, for the right amount of time. It means allowing you and your team to feel the exhilaration of completing valuable work. And it means stopping at the right time to allow that exhilaration buoy your team along so they can all reach the finish line together.

This week, I was re-reading one of my favorite books called “What I Talk About When I Talk About Running” by Haruki Murakami. It’s not a book about business, agile, or lean product management. It’s actually a memoir written by an amazing novelist about running and training for marathons. And every time I read this book, I always find this passage the most interesting, especially for lean or agile teams:

“Right now I’m aiming at increasing the distance I run, so speed is less of an issue. As long as I can run a certain distance, that’s all I care about.” Sometimes I run fast when I feel like it, but if I increase the pace I shorten the amount of time I run, the point being to let the exhilaration I feel at the end of each run carry over to the next day. This is the same tack I find necessary when writing a novel. I stop every day right at the point where I feel I can write no more. Do that, and the next day’s work goes surprisingly smoothly. I think Ernest Hemmingway did something like that. To keep on going, you have to keep up the rhythm. This is the important thing for long-term projects. Once you set the pace, the rest will follow. The problem is getting the flywheel to spin at a set speed – and to get to that point takes as much concentration and effort as you can manage.”

Murakami doesn’t use the specific words, but he is describing what the lean and agile world refers to as sustainable pace. Lately, I’ve seen far too many organizations forget that sustainable pace is an important component of lean and agile systems. They push too hard, for too long and in the end sacrifice the health and well-being of their team members, and produce lower quality products. Sustainable pace allows teams and individuals to remain healthy, produce higher quality products, and to be more predictable in their output.

So, let’s break down Murakami’s quote and see if it helps us understand sustainable pace a little better.

“Right now I’m aiming at increasing the distance I run, so speed is less of an issue. As long as I can run a certain distance, that’s all I care about.” To me, this is the definition of done. My team knows the deal, knows what we have to deliver, and that we will get to done. Speed is not always the most important thing. Sometimes high quality and getting the right things done are more important than how fast something gets to market.

“Sometimes I run fast when I feel like it, but if I increase the pace I shorten the amount of time I run, the point being to let the exhilaration I feel at the end of each run carry over to the next day. This is the same tack I find necessary when writing a novel. I stop every day right at the point where I feel I can write no more.” I don’t believe that sustainable pace means a constant pace. The Agile Manifesto states, “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” I think sustainable pace needs to allow for the natural flow and ebb of energy through a team and through individuals. As Christoph Baudson describes it, sustainable pace means that work should happen dynamically by expending energy and then restoring it by the use of rituals. Stop and slow down at the right times so you and your teams can experience the exhilaration of the work they have done and let that carry on to the next day, sprint, or release.

“To keep on going, you have to keep up the rhythm. This is the important thing for long-term projects. Once you set the pace, the rest will follow.” While I don’t believe sustainable pace equals constant pace, I think it does imply a natural rhythm. If we are running a marathon, we can’t continuously run record setting sub-4 minute miles. It’s not a rhythm anyone could keep for 26.2 miles. You’ll bonk after a mile or two and never complete the race. But how do you know what pace you should run to complete a marathon? Or, how do you and your team know what the correct pace is to complete a project and remain healthy and happy? It’s trial and error. Try a pace that your team agrees to. Run a sprint or two. Do a retrospective. Were we running too fast? Too slow? Just right? Ask the questions, get the answers, and adjust your pace until it feels right for everyone.

“The problem is getting the flywheel to spin at a set speed – and to get to that point takes as much concentration and effort as you can manage.” Getting to a predictable pace is not easy. It takes a lot of effort. And it depends heavily on complexity. In terms of running, it depends on the terrain you are covering. Most road races are relatively flat, on pavement, with fairly predictable conditions. I know that when I run a road marathon I can run at a fairly fast pace. However, I also race a good deal of off-road trail marathons, and the pace I maintain in those races is significantly slower. Trail races throw a variety of conditions at you that can change dynamically…uphill, downhill, rolling, steep, rocky, sandy, wet, muddy…you name it, it’s out there. It takes a lot more effort and concentration to find a sustainable pace on the trail than it does on the roads. In the same way, it will probably take less effort for you and your team to get to a sustainable pace on less complex work than it will on more complex work.

So remember to expend only the right amounts of energy to get the right things done. Slow down or stop from time to time to allow your teams to restore that energy and enjoy the exhilaration of completing valuable work. Experiment with a variety of paces until your team finds a natural rhythm that works for them. And know that your pace does not need to be constant. Allow it to ebb and flow depending on the terrain of complexity. Run your teams at a sustainable pace and I promise you’ll not only reach the finish line, but you’ll feel great on the entire journey.

The post What Can Haruki Murakami Teach Us About Sustainable Pace? appeared first on LeadingAgile.

Categories: Blogs

Introducing: Milestones

Rally Agile Blog - Tue, 11/11/2014 - 15:00

If you've scaled Agile across multiple teams, then you're likely doing regular sprint planning and you’ve developed a predictable cadence for releasing software.

Getting your teams to run like a well-oiled machine is all well and good, but the real value of scaled Agile comes from aligning your development and release cycles to your organization’s business priorities. You might have an important market event — a meeting or industry conference — driving a release deadline. What if your operations group is doing a system-wide upgrade, and you need to schedule a release around it? Maybe you’re shutting down your offices over the winter holidays and need to work that into your planning.

When it comes right down to it, what you build doesn’t have business value until you deliver it to the end user. So if your delivery schedule is tied to important events, you need to be able to include these events in your development planning and tracking.

The Scaled Agile Framework (SAFe™) refers to this as “Develop on Cadence, Release on Demand.”  

Rally’s new milestones feature allows you to easily plan, track, and steer your work to both your development cadence and key internal or external events. With milestones you can link stories, features, or whole releases to a particular date: a market event, a trade show, or an important code deployment.

How Milestones Work

Milestones help you coordinate work across teams to deliver the right work at the right time, and let you see how work is unfolding in alignment with a key market deadline. Milestones also give executives and other stakeholders immediate, realtime visibility into your progress toward your business priorities.

Imagine, for example, that you want to release a shopping cart feature with four components in time for Black Friday, one of the biggest shopping days of the year. You’ll want to track your progress on the four components and make sure they’re all coming together on-time, so you can release the feature as planned. If one of the components isn’t on track, you’ll know from watching your Black Friday milestone whether your feature release is at risk.

How to Use Milestones

You’ll find the milestones page under the plan tab. When you create a milestone, you’ll give it a name and a target date, and you’ll choose which projects are linked to it.

You can link multiple work items to a milestone all at once, using bulk actions.

When editing the detail page for any item — a story, feature, defect, etc. — you can see the milestone(s) associated with that item.

You can also view milestones in the portfolio timeline. Click on the milestone icon to see the milestone’s name and date.

To see all the work associated with a particular milestone, select the filter button from the portfolio timeline page or the milestones page.

When you associate a work item to a milestone, you implicitly associate all the child items of this work item. For example, say you connect a feature to a milestone: you won’t see the milestone indicated on the child stories under the feature, but when you’ve completed all the child stories that roll up to that feature, then the feature will indicate that the milestone goal is met. Alternately, say you’ve got 10 child stories under a feature, but only 5 of them are associated to a particular milestone. In this case you’ll want to link these 5 stories directly to the milestone, rather than linking the milestone to the feature.

Chart Your Progress Against a Milestone

In the same way you might watch stories or releases, you can create a burnup chart against a milestone, too.  

You can also chart your development cadence against specific milestones to see how they map up. On the chart below you’ll see that the milestone for “2.0 Private Beta” (represented by the dotted line) does not align with a program increment boundary. 

Ensure Your Highest-value Work Hits Critical Market Windows

Do you have important deadlines, events, or releases across your organization, and need to get everyone aligned to them? Create and track milestones in Rally and you’ll automatically connect your most important development work to the critical windows your business needs to hit.

In Rally you’ve got all the support you need to develop on a predictable cadence, AND release on a market-driven demand. Using milestones can ensure that your organization is not only building the right things, but delivering them when your customers and the market need them most.

Learn more about high-performing Agile at scale with Rally Program Launch

Shannah Van Winkle
Categories: Companies

How do I still write code as a Tech Lead?

thekua.com@work - Tue, 11/11/2014 - 12:34

I have previously suggested that effective Tech Leads spend an ideal minimum of 30% of their time writing code. A common question I hear in the Tech Lead training course I run is:

Where do I find the time to code when I have all these other responsibilities to take care of?

I know that many Tech Leads struggle to find the right amount of code, and also struggle to know what sort of tasks to take on. Here are some useful bits of advice that have helped me and others:

Avoid working on critical path items

Although Gantt charts have a bad name in IT, they do serve a useful visual model for depicting critical chains and seeing the critical path. A Tech Lead will usually find themselves interrupted and finding a solid block of coding time will be unusual. As a guideline, I advise Tech Leads not to focus on critical path tasks because they will often block progress on those tasks.

If a critical path item requires knowledge or experience, that only the Tech Lead has, it is useful to work with another developer on the task, so that progress continues when the Tech Lead works on responsibilities.

Learn to delegate

Delegating is a skill that Tech Leads must develop, and a skill that developers rarely have an opportunity to build. The Situational Leadership Model clearly explains when to delegate. Effective delegation depends on the skill and motivation of an individual. The model explains four modes: Telling, Selling, Participating, Delegating with the end goal of aiming to delegate as much as possible.

Delegating is only possible when a leader believes someone has the sufficient skill and sufficient motivation to complete a task.

A common challenge for many Tech Leads is trusting that someone other than them writes code good enough to complete an appropriate task.

Loosely pair program

I’m not a big believer in full time pair-programming. But finding the right balance between full-time and nothing is hard to achieve. A good arrangement is to work with someone on the approach or design for a particular problem, and then to do regular reviews (or short pair-programming sessions) to see what new information or challenges emerge as code is written.

This style of “co-working” on the design and code works well for a Tech Lead, who will find themselves constantly interrupted.

Avoid unnecessary or poorly run meetings

There is nothing worse for a programmer to sit in a meeting which has no purpose or no outcome. These are frustrating because the time spent in the meeting is waste. Learn how to run effective meetings, to avoid the frustrations of ineffective meetings.

Use the “5 P’s of Effective Meetings” model:

  • Purpose – Is it clear what the meeting is for? Ensure each meeting has one clear purpose. Examples include: Distributing information, gathering information, brainstorming solutions, and seeking agreement or consensus.
  • Product – You can cut a meeting short, when you know what the outcome of that meeting should be. Define success criteria for the meeting (which will be related to purpose) to keep meetings focused and on track.
  • Participants – It is better to cancel/reschedule a meeting than to hold a meeting with the wrong people. This tweet from Esther Derby summarises it very well. Pointless Meetings
  • Probable Issues – What are the concerns or questions that will be raised during the meeting that need to be addressed, or threaten to derail the meeting?
  • Process – Every meeting should be clear about how the meeting will be run, how people are expected to participate, and special rules of what might need to be done. A meeting facilitator should start with clarifying the purpose of the meeting to reset people’s expectations.
Learn to say no

The art of leadership is saying no, not saying yes. It is very easy to say yes. — Tony Blair

As a Tech Lead, you will be pressured to always take on more than you can possibly take on. The more activities you say yes to, the less time a Tech Lead has to code. If coding is really important to you (and it should be), then you need to develop an awareness of what things are really important and those that can be done by others or by non-technical people.

Block out coding time

I know some Tech Leads who block out calendar time in their diary on a regular basis to ensure that they have uninterrupted time to code. Developers know how interruptions break the train of thought and Tech Leads will find themselves even more interrupted in comparison to developers.

Conclusion

It is important a Tech Lead spends time writing code but the other responsibilities demand time away. Keeping the balance right is tricky, but the techniques described above can help you cutting code. Please leave a comment if you have other suggestions.

If you liked this article, 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.

Categories: Blogs

Wie man mit Transparenz ein Produkt zum Fliegen bringt – das Projekt-Cockpit

Scrum 4 You - Tue, 11/11/2014 - 08:53

Man streitet sich immer wieder darüber, was Scrum eigentlich ist. Ist es ein Management-Framework? Oder doch ein Mindset? Oder gar eine Projektmanagementmethode? Vielleicht doch eher ein Prozess? Für mich ist es all das und noch viel mehr: nämlich auch eine Methode, um Probleme ans Tageslicht zu bringen. Durch die Transparenz, die in Scrum-Projekten gegeben ist, kann man Risiken und Hindernisse schnell erkennen und darauf (hoffentlich) frühzeitig mit einer Lösung reagieren.

Doch wie stellt man diese Transparenz in Scrum eigentlich her? In den unterschiedlichsten Projekten versuche ich stets, das gesamte Produkt bzw. Projekt an einem Ort haptisch abzubilden, um einen kompletten Überblick zu bekommen. Und ja, wir reden hier von Flipcharts, Brownpaper und Post-Its an der Wand. In diesem Blog möchte ich einen kurzen Überblick über eine für mich optimale Form eines „Projekt Cockpits“ geben.

Was?

  • Transition Backlog und Taskboard für das Transition Team
  • Skaliertes Impediment Backlog und Taskboard für das ScrumMaster Team
  • Product Backlog und Taskboard für das Product Owner Team
  • SoS Board und Release Burn-Down Chart für die Dev.Teams

Wie?
All diese Boards, die man in der skalierten Scrum-Umgebung typischerweise vorfindet, würde ich an einem Platz zusammenhängen. Je nachdem, wie die Teams strukturiert sind und ihre Meetings leben, kann man die Reihenfolge der Boards anpassen, gewisse Boards zusammenlegen oder überhaupt andere Boards nutzen. Ob man die Wände eines Büros, eines Ganges oder eines Aufenthaltsraumes nutzt, ist letztendlich egal – wichtig ist nur, dass es ein zentraler Ort ist, damit die Macht der Transparenz über die Lieferung auch wirklich genutzt wird.

Wer?
Am besten ist es, wenn jedes Team sein Board selbst gestaltet und sich überlegt, wofür es dieses nutzen möchte, welche Informationen darauf abgebildet sein sollten und wie es gepflegt werden wird. Generell bedarf es hier eines Commitments und der Mitarbeit aller Projektbeteiligten.

Wozu?
Einer der wesentlichen Benefits von Scrum ist die verbesserte Kommunikation innerhalb von Projekten und Organisationen. Dieses Projekt Cockpit verbindet Kommunikation mit Transparenz auf zwei Arten: Erstens wird hier die erledigte Kommunikation abgebildet (z.B. Impediments aus dem ScrumMaster- bzw. Tasks aus dem Transition Team Daily werden aufgeschrieben und aufgehängt) und dadurch entsteht eine Art Protokoll für die restlichen Mitarbeiter. Zweitens passiert es regelmäßig, dass jemand dort einen Task oder ein Impediment vorfindet, bei dem er selbst schon einmal etwas gemacht hat bzw. das er lösen könnte, wenn er nur davon gewusst hätte. Im Sinne der Nutzung von Synergien und Lieferung kann einem Projektteam doch nichts Besseres passieren!

Kleiner Hinweis: Anfangs dauert es meist ein wenig bis das Cockpit ins Laufen kommt, doch wenn es dann von allen genutzt wird, hilft es ungemein. Probiert es doch mal aus oder habt ihr selbst auch schon (andere) Erfahrungen mit dieser Art von Projekttransparenz gemacht?

Zum Schluss noch ein Beispiel-Cockpit aus einem aktuellen Projekt:

IMG_6038

Related posts:

  1. Bitte geben Sie Ihr Ziel ein! Tipps für das Transition Team
  2. Scrum Tools | Scrumy.com | Review
  3. Scrum – Produkte zuverlässig und schnell entwickeln

Categories: Blogs

R: dplyr – Sum for group_by multiple columns

Mark Needham - Tue, 11/11/2014 - 02:17

Over the weekend I was playing around with dplyr and had the following data frame grouped by both columns:

> library(dplyr)
 
> data = data.frame(
    letter = sample(LETTERS, 50000, replace = TRUE),
    number = sample (1:10, 50000, replace = TRUE)
    )
 
> data %>% count(letter, number) %>% head(20)
Source: local data frame [20 x 3]
Groups: letter
 
   letter number   n
1       A      1 184
2       A      2 192
3       A      3 183
4       A      4 193
5       A      5 214
6       A      6 172
7       A      7 196
8       A      8 198
9       A      9 174
10      A     10 196
11      B      1 212
12      B      2 198
13      B      3 194
14      B      4 181
15      B      5 203
16      B      6 234
17      B      7 221
18      B      8 179
19      B      9 182
20      B     10 170

I wanted to add an extra column which would show what percentage of the values for that letter each number had.

If we wrote that code standalone we’d have the following:

> data %>% count(letter)
Source: local data frame [26 x 2]
 
   letter    n
1       A 1902
2       B 1974
3       C 1911
4       D 1948
5       E 1888
6       F 1975
7       G 1914
8       H 1886
9       I 1910
10      J 1924
11      K 1974
12      L 1891
13      M 1894
14      N 1946
15      O 1956
16      P 1934
17      Q 1865
18      R 1992
19      S 1946
20      T 1854
21      U 1919
22      V 1913
23      W 1928
24      X 1934
25      Y 1908
26      Z 1914

We can also get that value by summing up the individual (letter, number) pairs from the previous data frame. The ungroup function allows us to do so:

> data %>% count(letter, number) %>% ungroup %>% group_by(letter) %>% mutate(sum.n = sum(n)) %>% head(20)
Source: local data frame [20 x 4]
Groups: letter
 
   letter number   n sum.n
1       A      1 184  1902
2       A      2 192  1902
3       A      3 183  1902
4       A      4 193  1902
5       A      5 214  1902
6       A      6 172  1902
7       A      7 196  1902
8       A      8 198  1902
9       A      9 174  1902
10      A     10 196  1902
11      B      1 212  1974
12      B      2 198  1974
13      B      3 194  1974
14      B      4 181  1974
15      B      5 203  1974
16      B      6 234  1974
17      B      7 221  1974
18      B      8 179  1974
19      B      9 182  1974
20      B     10 170  1974

Pretty neat!

Categories: Blogs

R: dplyr – Maximum value row in each group

Mark Needham - Tue, 11/11/2014 - 00:06

In my continued work with R’s dplyr I wanted to be able to group a data frame by some columns and then find the maximum value for each group.

We’ll continue with my favourite dummy data set:

> library(dplyr)
 
> data = data.frame(
    letter = sample(LETTERS, 50000, replace = TRUE),
    number = sample (1:10, 50000, replace = TRUE)
    )

I started with the following code to count how many occurrences of each (letter, number) pair there were:

> data %>% count(letter, number)
Source: local data frame [260 x 3]
Groups: letter
 
   letter number   n
1       A      1 184
2       A      2 192
3       A      3 183
4       A      4 193
5       A      5 214
6       A      6 172
7       A      7 196
8       A      8 198
9       A      9 174
10      A     10 196
..    ...    ... ...

I wanted to find the top number for each letter and with a bit of help from Stack Overflow I ended up with the following:

> data %>% count(letter, number) %>% filter(n == max(n))
Source: local data frame [26 x 3]
Groups: letter
 
   letter number   n
1       A      5 214
2       B      6 234
3       C      8 213
4       D      6 211
5       E      9 208
6       F      2 219
7       G      1 213
8       H      2 208
9       I      9 220
10      J      7 213
11      K      3 228
12      L      2 206
13      M      3 212
14      N      4 222
15      O      1 211
16      P      7 211
17      Q      9 210
18      R      5 224
19      S      2 211
20      T      9 204
21      U      8 217
22      V      6 220
23      W      2 213
24      X      2 214
25      Y      3 211
26      Z      3 206

Here we’re filtering over a collection of rows grouped by letter and only selecting the row which has the max value. We can see more clearly what’s happening if we filter the data frame to only contain one letter:

> letterA = data %>% filter(letter == "A") %>% count(letter, number)
> letterA
Source: local data frame [10 x 3]
Groups: letter
 
   letter number   n
1       A      1 184
2       A      2 192
3       A      3 183
4       A      4 193
5       A      5 214
6       A      6 172
7       A      7 196
8       A      8 198
9       A      9 174
10      A     10 196

And now let’s apply the filter command while also printing out information about each row:

> letterA %>% filter(print(n), print(n == max(n)), n == max(n))
 [1] 184 192 183 193 214 172 196 198 174 196
 [1] FALSE FALSE FALSE FALSE  TRUE FALSE FALSE FALSE FALSE FALSE
Source: local data frame [1 x 3]
Groups: letter
 
  letter number   n
1      A      5 214

If instead of getting the top number by letter we wanted to get the top letter by number we just need to reorder the field names in the count method:

> data %>% count(number, letter) %>% filter(n == max(n))
Source: local data frame [10 x 3]
Groups: number
 
   number letter   n
1       1      G 213
2       2      F 219
3       3      K 228
4       4      N 222
5       5      R 224
6       6      B 234
7       7      B 221
8       8      U 217
9       9      I 220
10     10      O 209

And if we want to see the letter that shows up least frequently we can change the call to ‘max’ to an equivalent one to ‘min':

> data %>% count(number, letter) %>% filter(n == min(n))
Source: local data frame [11 x 3]
Groups: number
 
   number letter   n
1       1      H 166
2       2      O 160
3       3      E 156
4       4      R 169
5       5      L 169
6       6      I 164
7       7      H 170
8       7      I 170
9       8      Q 166
10      9      W 162
11     10      J 168
Categories: Blogs

Time to Celebrate with Great Reviews!

Agile Management Blog - VersionOne - Mon, 11/10/2014 - 23:58

Someone recently asked me what one thing would make any company’s Agile transformation and adoption more successful? Almost before the question left their lips, I shot back – “great reviews, company-wide great reviews!” The most mature Agile organizations I’ve seen have regularly scheduled company-wide review meetings. These reviews are light on presentation and heavy on demonstrating working successes. The other positive factor for these review ceremonies is that they have active participation by managers, leaders and C-Level executives. These organizations regard reviews as sacrosanct, too important or valuable to be interfered with.

During my Certified Scrum Master (CSM) training a few years back, our class was struggling to find an answer to the Magic Management Metric question. The Metric that enables managers to say, “Ah-ha! Now I get this whole touchy-feely, self-organized Agile mindset thing.” Our instructor was a little put off by the idea that we needed to prove our worth and the value Agile brings to the powers that be at our respective companies. His terse final answer was that “If a leader wants to know what the team is doing, come to the review!”   After all, valuable working software delivered on a continuous basis trumps everything, doesn’t it?

Unfortunately, the reality is that the teams have become victims to our own self-crated Frankenstein’s monster. Most self-managed teams haven’t made it easy for leaders to attend even a handful of reviews. Each team plays by their own set of rules: some use two week iterations, some deliver daily but you can probably be sure that only 10%-20% of the reviews happen on the same day and even fewer happen at the same time.

This could be one of the driving factors towards the need for a more scaled multi-team view for agile delivery that is becoming more popular in the marketplace today. Process and program are seen as the glue that will bring various teams to communicate together. It’s not that companies don’t value individuals and interactions; they just value process and tools more, because the other way isn’t working too well.

The reality is that it is still desirable and possible to deliver customer value across self-organized lean teams, and many great companies are succeeding in doing so.   One way is by adopting regularly held All-Company Agile celebratory review meetings to help foster the collaboration and communication team need to be more effective. It’s still about the interactions and delivering working software. For any enterprise looking for a better way to radiate information on a consistent and customer focused way, here are some ideas to help your teams and leaders engage and execute healthy “All-In” review ceremonies:

  • Have ONE all-company review meeting; every team and every leader should be represented. This is sacrosanct, and it is the highest priority meeting on people’s calendars.
  • Teams need to synchronize their review cycles to a regular meeting cadence. This can be helped by having teams align to their iteration schedules.keep-calm-and-review-it
  • Have a set schedule order for who is speaking, but don’t over prepare. Keep it concise, but allow enough time to show each team’s results.
  • Each team gets an opportunity to demo their valuable customer working software during the review. Use collaborative online meeting options like GoToMeeting, if you have distributed teams.
  • When it makes sense, show your customer using the new and improved software. DevJam’s David Hussman recently recommended using your mobile devices to record customers demoing the software as a great way to accelerate Product Driven Learning. You don’t need a documentary, just live, real video feedback.
  • Reviews should be Agile method agnostic. You can regularly review the valuable accomplishments of SCRUM, XP and KANBAN teams at one time. It’s okay!
  • Cheering, hooting, clapping, and congratulations are encouraged. It’s called a celebration for a reason. Woot, Woot!
  • Feedback is encouraged, but even more important is having leaders engaged, present and observing what is and is not working and learning how to, as www.IllustratedAgile.com’s Leadership Engagement model shows, Encourage Monitor and Remove Big Impediments to support future team success.
  • Facilitate the time for feedback collection and Q&A to help keep the meeting on track. Use other creative methods like breakouts, note cards, or a simple post-review on-line survey to collect and report feedback back to the product owners and teams.
  • Course correcting is still reserved for the team-led retrospectives. Teams should regroup soon after the review, provide feedback and make tuning observations to improve future results. Then the actions should be shared, and provided to the appropriate levels across the org.

The interesting thing I’ve discovered from observing All-In reviews is that when everyone from the CEO down to the Summer Intern celebrates the wins of two weeks of effort, multiplied by many teams delivering substantial value to customers on an early and often basis, everyone wins. EVERYONE!

What types of actual results might you begin to see using ALL-IN reviews?

Team health becomes more transparent and the need for health-check driven metrics is reduced.   This increases the time available for productivity gains and the overall delivery team morale. Quality is more apparent, defects are reduced and the feeling that I should check my Facebook or LinkedIN pages at work goes down. Leadership’s motivation to remove impediments and understand “the system” and the knowledge of what is truly going on goes-up. And finally, the ability to achieve shared company-wide goals and demonstrate the ways teams are impacting customers in a positive consistent way is recognized and encouraged to thrive.

Tom Peters says you should “Celebrate what you want to see more of.”  Our highest priority should be to review team accomplishments, promoting even more success, more agility and more happy customers!

Categories: Companies

Timeboxing, Lateness and Character

Learn more about our Scrum and Agile training sessions on WorldMindware.com

I just finished reading a great rant about being on time by Greg Savage.  It got me thinking a bit.  I’ve been involved with Scrum and other Agile methods since the mid-90′s and in that time, my perspective on time has changed considerably.

saving time clock

I used to be the guy who was always late.  And it was a completely selfish behaviour.  Meetings, outings, even weddings.  I just couldn’t believe how “uptight” people were about time.  But gradually, over a period of about 5 years as I became more and more aware of the underlying philosophy of Agile, my perspective, and more importantly my behaviour, changed: I started being on time.  For everything.  Even if it meant doubling my travel time buffer.  Even if it meant sleeping 3 hours instead of 8 hours.  Even if it meant missing a meal or a drink or a personal to-do item.

Time is the only resource that, once spent, we can never get back.

Scrum and most other Agile methods respect this implicitly in their time-boxed iterations and meetings.  But people on Agile teams often need time to adapt and change their behaviour.  In many ways, timeliness (starting and finishing meetings on time) is a critical component of the Scrum value of Respect.

Timeliness is also related to our understanding of planning.  The Horizon of Predictability is short in most work environments.  Maybe a week or two.  If you dis-respect the tkmeboxes of the Agile process, you are jeopardizing your ability to effectively use the horizon of predictability.  Even the Daily Scrum, normally time boxed to 15 minutes each day, can through abuse of time, cause long-term ramifications in product development planning.

But really, I like Greg Savage’s point better than all the practical stuff: being late is rude.  Period.

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!
facebooktwittergoogle_plusredditpinterestlinkedinmail
Categories: Blogs

Push v. Pull: A Leadership Story

Agile Tools - Mon, 11/10/2014 - 22:26

sailing

It hadn’t been a very good race. In fact, it wasn’t an understatement to say it had been a disaster. To Peter Smith it was embarrassing just to show his face in the clubhouse afterward. He was at a complete loss to explain how it had happened. He felt like had just managed to snatch defeat from the jaws of victory.

He’d put together a decent crew. There were no rookies on the boat. Everyone knew their jobs and some had even sailed together before on other boats. Some even had more experience sailing than Peter did. It should have been a pretty decent team.

The boat was brand new. It was the latest club racer with all the bells and whistles. It was blazing fast on the water upwind and downwind. They had all the right equipment, the right sails, and every reason to win.

That’s why their performance was all the more frustrating for Peter. They’d sucked. There was no getting around it. He felt like he’d made all the right moves and still managed to fail. He’d reviewed it backwards and forwards and still had no idea what to do. It was definitely time for a beer.

Still licking his wounds Peter took a seat at the bar. Things were hopping and the whole place was abuzz with sailors recounting the day’s action. It happened that Pete had picked a spot next to one of the club’s old timers, Rex. Pete knew him only by reputation, but he was supposed to be one of the best racers in the club.

Rex was the gregarious type and soon introduced himself to Peter and asked how his race had gone. Beer now in hand, Peter proceeded to tell the story of the day’s humiliation.

“We went out on the water early and did some practicing before the race. We needed to get used to working with each other and get the kinks straightened out. We had no problem there. A few short tacks, a few gybes and we were ready to go.

So race time comes around and we get to the start and begin working for a good spot on the starting line. You know how it is, it’s a tough fleet, so there are lots of boats and they are all pretty intense. If you leave those guys an opening, they are going to take it and you can kiss a good start goodbye.

This is where we had the first hint that there might be an issue. As the maneuvers on the start line became more intense, the crew execution started to weaken. A boat would cut us off and we would have to spin to avoid them. As we would execute the spin, one of the trimmers would make a mistake and we would get stuck, stalled out behind the line.

Of course we would recover and try again, but is was the same story all over again. I’d have to execute another rapid maneuver and the trimmers would blow it again! It was intolerable. I began to yell, because we were never going to win a race performing like this. I don’t think the yelling helped much (in fact they seemed kind of annoyed), but what else was I supposed to do? I couldn’t exactly trim the sheets for them, could I?”

Peter saw Rex frown as he described this last bit, but he was starting to get some momentum in the story, so he powered on, “Anyway, when the starting gun when off, we weren’t in a good position and ended up starting in the second rank, sucking wind behind all the good guys who had managed to get off the line with good starts.

From there, things went tolerably well on the first beat to the windward mark. We did the best that we could with a bad start, but we still ended up toward the back of the fleet as we prepared to round the windward mark. Strategically, there wasn’t much we could do until we reached the mark, and we managed to execute well, with no major screw ups.

Of course that all changed when we reached the mark. That’s where everything fell apart. As we rounded the mark, the bowman wasn’t ready and we launched the spinnaker late as I was trying to gybe set and cover the competition. Nobody was ready! We ended up with the spinnaker wrapped around the forestay and the bowman was screaming at the trimmers to ease up on the sheets. There he was on the foredeck, flailing away trying to untangle the mess, as boats went by us on either side. Jesus was he slow! I hollered at him to hurry up, but I don’t think he was listening, because nothing changed. It was costing us the race.

Finally we got the spinnaker sorted out and we got ourselves back in the race. Only now we were at the very back of the fleet. That’s right, we were dead last. As if that weren’t bad enough, when we eventually got to the leeward mark, it was an even bigger disaster!”

Peter paused for a sip of his beer and continued, “I told the crew that we had to move faster to keep in the race, but it didn’t help. They just couldn’t execute. By the time we crossed the finish line, there was complete silence on the boat. No cheers from the crew. We all felt like we never wanted to do that again. I’m completely baffled. How could this have happened? Where can I get a good crew? I need a crew that can execute, not a bunch of whiners who shout at each other when things go wrong.

Look, I can’t change that it’s a race. We’re not in this to have a good time. We’re here to win a race. Why can’t anybody understand this? I need a little positive attitude here. I need people with a will to win! Where can I get some of that? We sucked!”

There was a long moment of silence. Rex was shaking his head and chuckling quietly to himself. He paused and looked at Peter with an assessing sort of gaze and said. “That’s a helluva story. I’ve seen it before. You want my advice?”

Peter looked down and swirled the beer at the bottom of his pint thoughtfully for a moment. Then he looked up and replied, “At this point, yes. I’ll do anything.”

“Buddy, what you are doing is pushing these guys, and what you really should be doing is pulling with them. You don’t succeed by pushing a team, you succeed by pulling along with them.” He said.

Peter frowned, “What the hell are you talking about?”

Rex paused to take another sip of his beer and continued. ”It’s like this, You can push the problems on the team. You can make it all their problem. In that situation, at the best, you are simply not helping, and at the worst, you are actually creating additional problems for the team.”

“Problems? What do you mean? I don’t give problems.” objected Peter.

“Hold on, let me explain: Let’s take your race today as an example. When you were maneuvering on the start line, what did you do to your trimmers?” Rex asked.

“I didn’t do anything to them. I spun the boat about and it was their job to trim the sails properly to execute the spin.”

“And did you tell them you were going to spin, or did you just slam the tiller over and wait for them to figure it out?” Rex tilted his head as he asked this last question.

“Well…I had to spin. I didn’t have any choice. Otherwise we would have hit another boat.” Peter said rather defensively.

“OK, so you had to spin, but you didn’t tell anyone what you were going to do, right?”

“OK, alright, yeah.”

“So, here’s the question: When you do that, turning without telling anyone, are you suddenly creating a problem for the trimmers or are you helping them?”

“Well OK, it’s not helping I guess.”

“That’s right. You’re creating a challenge or impediment for the trimmers to overcome – you’re pushing the problem on them. Not only do they have to trim the sails as fast as they can, but they also have to be mind readers – guessing at when you may spontaneously change direction without telling them.

Let’s look at this another way. What could you do to help them?”

Peter looked a bit sheepish and said, “I could call out the maneuver before it happens?”

“Right, if you did that you would be helping to make their jobs easier. You would be setting them up to succeed rather than setting them up to fail. You would be contributing to the successful execution of their work.”

“Yeah, I guess.” Peter said a little petulantly. “But I’m still not really sure what you mean by this ’pushing vs. pulling’ thing.”

“OK, well let’s talk about that mark rounding you did. What do you have to do to round a mark?”

“Hundreds of things!” Peter exclaimed. “Everyone has dozens of tasks that they each have to perform in a choreographed fashion in order for a mark rounding to be successful.”

“And what did you do to help them round the mark?”

“I did the steering, their jobs are their problem.”

“So again, how could you help?”

Peter gave it some thought and then said rather tentatively. ”Call out the maneuver?”

“Yes. What else could you do to help?” Said Rex.

“Well, I suppose I could slow down the turn in order to give them more time to make their adjustments?”

“Bingo!” exclaimed Rex. “That’s more like it. You have to be thinking of what you can do for the team to make their jobs easier. You need to think beyond your own role and be constantly asking yourself: How can I help the team? What can I do to help this team work like a well oiled machine? As long as you are thinking only of your job, you aren’t really part of the team. To be part of the team, you need to be pulling along with them to help them reach the goal.”

Peter nodded his head, “OK, I think I get that, but it’s kind of abstract don’t you think?”

“No, not really. I see it out on the race course all the time. You get these hyper competitive types rushing about without thinking about the team. They rush through mark roundings thinking only of themselves and winning the race and not about the crew. The poor crews are pulling as hard as they can, but they just aren’t in synch with the helmsman. They aren’t pulling together as a team.

It’s push vs. pull.” he finished.

Peter looked down pensively and was quiet for a minute. Then he called over the barkeep and bought Rex another beer. “Thanks. I appreciate the advice. I’m going to have to give that try.”


Filed under: Agile, Blogroll, leadership, pull, push Tagged: leadership, pull, push, sailing
Categories: Blogs

Scrum and Kanban – Which one to use?

Agilitrix - Michael Sahota - Mon, 11/10/2014 - 21:28

Scrum is the most popular Agile methodology with Kanban a growing second choice. Learn about the core parts of each one as well as how they differ so that you can find the best fit for your team or organizational context. For example, Scrum is great when you want to shake up the status quo and transform the way you work. Kanban is great when small changes are a better fit for the environment. Learn how they work and how you can use them in your environment.

Scrum and Kanban – Getting the Most from Each from Michael Sahota How to Choose Between Scrum and Kanban Choosing Between Scrum And Kanban

Scrum will be more successful in environments where it’s requirements are met. If you have all six, Scrum is great. When you start loosing important bits of context it becomes more difficult.

Kanban is much more fault-tolerant and work in many more contexts.

The post Scrum and Kanban – Which one to use? appeared first on Catalyst - Agile & Culture.

Related posts:

  1. Beyond Roles in Scrum In this post we will explain how we can move...

Related posts brought to you by Yet Another Related Posts Plugin.

Categories: Blogs

Navigating Politics in Agile Teams

TV Agile - Mon, 11/10/2014 - 20:07
Have you ever wondered why, when you’ve finally got Agile/Lean working nicely in your software engineering team, managers or ‘outsiders’ can come in and create politics ‘un-necessarily’, despite your best efforts? Have you ever sat there in meetings frustrated and exasperated at the seemingly unnecessary dramatics some participants go through? Or, when you start an […]
Categories: Blogs

“The Wastes are Water”, and Other Advice from the Older Agile Fish.

BigVisible Solutions :: An Agile Company - Mon, 11/10/2014 - 19:42

I am a frequent speaker at conferences. People ask me “why do you go through all of that hardship to prepare and present?” My answer is that every time I put myself out, I gain more insight from speaking to people that I know and meet.  So, for me, it’s worth it.  A couple of weeks […]

The post “The Wastes are Water”, and Other Advice from the Older Agile Fish. appeared first on BigVisible Solutions.

Categories: Companies

Knowledge Sharing


SpiraTeam is a agile application lifecycle management (ALM) system designed specifically for methodologies such as scrum, XP and Kanban.