Skip to content

Feed aggregator

Agile Israel, Tel Aviv, Israel, June 9-10 2015

Scrum Expert - Thu, 05/07/2015 - 15:01
Agile Israel is a two-day conference that discusses Agile, Scrum and Lean topics. It aims to attract Agile Managers, Scrum Masters, Product Owners and Coaches to discuss and network around these themes. The second day is dedicated to tutorials and workshops. In the agenda of Agile Israel you can find topics like “Recharging/Boosting your Agility”, “Create Leaders at Every Level”, “Dealing with Shifting Priorities using Lean/Kanban Flow, WIP Limits and Capacity Allocation”, ” AdvanScrum”, “Feature discovery through Design Thinking”, “M-Agile – Best practices for successful Mobile Agile”, “BDD from the Trenches”, ...
Categories: Communities

Improving Agile Portfolio Management Coordination

Agile Management Blog - VersionOne - Thu, 05/07/2015 - 14:30

shutterstock_111588257

 

 

 

 

 

 

 

 

Simply producing status reports in an enterprise with hundreds of software development teams isn’t enough to ensure that your products will be delivered on time. You have to ensure that the plans, dependencies, progress and schedules of those teams are all coordinated.

So, how can you coordinate the software delivery across multiple large-scaled systems across hundreds of enterprise software development teams?

Enterprise Software Development Coordination

Whether you’re coordinating several teams or hundreds of enterprise software development teams, you need clear visibility of plans, dependencies, progress and schedules across your portfolios, programs and projects. While it’s simple and easy to look at just a single feature and understand the dependencies and progress of various teams, it’s much more complex when you’re working with a portfolio or program that includes many features that can raise questions about what should be prioritized first in the various backlogs. As a portfolio or program manager you have to do some juggling, planning and coordination to make sure that the portfolio and program level features are moving and progressing as they should, and that all of the work that is needed to support and deliver your programs is really happening down at the team levels.

Let’s take a relatively simple example of an organization with multiple products in a suite. Each product has a team dedicated to its development. Some features are product specific and left to the product owners to drive per product. Some organizational level initiatives, however, may cross all of the products to drive forward company-wide strategies. If this is, say a U.S. company with a corporate initiative to expand into foreign markets, there can be many product and organization ramifications. Sales and services capabilities must exist in Europe. Products must support Value Added Taxes and multiple currencies, perhaps even multiple languages. Support teams must be able to handle extended hours and languages. Clearly, there is a great deal of coordination required to deliver on such an initiative and the better a businesses can handle such a challenge, the better its chances of thriving in a global marketplace.

Coordinating Plans

Each product that an initiative touches must be delivered in a coordinated fashion to provide the most business value possible. So you must plan out an initiative that spans multiple systems as a whole unit. That starts with prioritizing the work at the initiative level, then prioritizing and scheduling the various features that need to be delivered across teams in order to realize the business value of that initiative. By planning first at the initiative and then feature level, we can minimize Work–In-Progress (WIP) and get more value delivered quicker.

From a coordination standpoint it’s important to be able to see what the teams are planning as they’re doing the work, and to see whether or not they look like they’re on track to be able to deliver at the level where the business value can actually be realized. If we have three systems that are all working together to support a given initiative and only two of the systems deliver their parts within the scheduled release, we’ve wasted the effort of the two teams that did deliver. Take for example a feature that essentially is a transaction that goes from system A to system B to system C. If systems A and C plan their features for Release 1, but B plans its feature for Release 2, we don’t get to realize the value of that initiative until Release 2. A and C would be better off planning capabilities for Release 1 that could be used by the customer when Release 1 is delivered.

Coordinating Dependencies

An important consideration in coordinating your software teams is to understand which stories and teams are dependent on each other to produce a working release of software. It’s important to be able to quickly understand where those specific dependencies exist and how they fit into your greater program. On related features across products, not every story will have a dependency. It is important to understand, identify and track those stories and features that have dependencies across teams. For example, system A may require an update to a central security component that is managed by a specialized team. Both system A’s team and the security component team need to understand that linkage, coordinate the timing and track the plans of the other team as they evolve.

Building a dependency diagram at the epic level of your program will help you understand what features and initiatives are dependent on each other. Mapping your program’s dependencies provides visibility into the teams that require extra coordination and communication to remain in lock-step so they can deliver your product on time.

Agile Portfolio Management Dependency Diagram Screenshot from VersionOne

Agile Portfolio Management Dependency Diagram Screenshot from VersionOne

 

Coordinating Progress

In addition to tracking progress at the team level, it is important to track at the feature and initiative level as well. Business value resides at these higher levels, so it is imperative that organizations work to track progress and throughput at that level to keep the focus where the business value lives. This is best accomplished by having Kanban boards to view and understand the progress at the various levels of your program. Depending on the size of your organization you may have multiple levels of planning and monitoring. Large enterprises typically have an overarching portfolio level, followed by a program level and finally a team or project level. At the portfolio and program level there are high-level initiatives that are being developed which will typically be decomposed into multiple features that may spread across several different systems. Those features then get broken down into stories the teams are going to deliver. To effectively monitor these multiple levels, you’ll want the flexibility of tracking each level independently and understanding the context of features and how they relate to the higher level initiatives being driven.
Agile Portfolio Management Kanban Board Screenshot from VersionOne

Agile Portfolio Management Dependency Diagram Screenshot from VersionOne

Agile Portfolio Management Dependency Diagram Screenshot from VersionOne

 

 

 

 

 

 

 

 

At the team or project level, create storyboards and make sure the individual stories are part of epics that represent a program or feature on your program board. Storyboards enable you to see all the low level details of stories and how those details roll up into a feature. This allows you to drill down into the next level of detail needed. By mapping your programs with epic boards and storyboards you have the visibility to see your programs’ high level flow, medium level flow and low level flow. The dependency diagram lets you easily understand which initiatives, programs, epics, projects and stories are dependent on one another so that you can coordinate their progress.

Coordinating Time

Easily viewing progress and dependencies across an entire portfolio helps overcome many of the challenges associated with scaling agile across large enterprises, but it will not cure all ills. In order to fully coordinate your portfolio and programs you must be able to view progress and dependencies in relation to your delivery schedule. This is where it is good to have a timeline view. Your timeline should be connected to your dependency diagrams, epic boards and storyboards, enabling you to drill down into initiatives, programs, epics, projects and stories.

Agile Portfolio Management Timeline from VersionOne

Agile Portfolio Management Timeline from VersionOne

 

 

 

 

 

 

 

 

With a timeline view you can take an initiative and drill down into the features. This allows executives and PMOs to have visibility into when all the features are scheduled within a single view. Within a single view you can get an understanding of whether or not the delivery dates for programs, features and stories are coordinated across various levels of the portfolio and programs. For example if you have an initiative that you’re thinking you’re going to deliver in June, but then when you drill down into it you see that you have features for that initiative spreading out into July and August, that could be a problem. Being able to see views like that enables you to understand what may be at risk and what changes may need to be made.

Coordinating the Portfolio

By tracking progress, dependencies and release dates you can easily coordinate the progress of your portfolio from the very highest level, that of the initiative, to the very lowest level, that of the stories. Coordinating the portfolio will help increase the throughput of business value. These three views enable you to drill down and be able to see the progress of all your features from a delivery standpoint. Are they completed? Are they in progress right now? Do we have some that we haven’t even started yet? What is the status? What are the plans for this? Epic boards, dependency diagrams and timelines provide you with visibility into the progress of all of your initiatives. They allow you to see all of the features that a given organization might be working on. Or, they can show you all of the features that roll up into a certain initiative, providing that next level of detail to see what’s where from a delivery standpoint.

Whether you are an executive, line of business person, or a program manager, you can take a look at whether your teams are coordinated up and down the portfolio, program and team delivery levels. Being able to track across the various levels is extremely important. That’s the ideal way to manage the course of delivery. We’re tracking, monitoring, watching and having conversations between those various levels of delivery.

Conclusion

Coordinating software delivery across an enterprise of software development teams isn’t easy. However, if you organize, plan and track your portfolio as laid out above, you will not only deliver software on-time but you’ll help your organization maximize the throughput of business value.

So, how are you coordinating software delivery? VersionOne can help. 

Categories: Companies

Update on RMQ For Developers: Consulting To Be Available!

Derick Bailey - new ThoughtStream - Thu, 05/07/2015 - 12:00

About a week ago, I announced my RabbitMQ For Developers bundle. This is a package of screencasts that I created for WatchMeCode, an eBook that I wrote on the same subject, and a series of interviews that I am doing with RabbitMQ and messaging professionals. 

I’ve been hard at work (seriously… this has been a TON of work!) and wanted to give an update on what’s going on, including a big announcement about a very limited edition of the bundle!

Update On The Bundle

As I mentioned previously, the screencasts are complete. I don’t have any remaining work on these. 

The eBook is also content complete at this point! It’s 8 chapters and 2 parts, with the second part of the book covering the human side of working with RabbitMQ – the learning, the experiences of figuring things out, and the seemingly random places from which inspiration comes. I’m currently working on edits for the book, with a friend doing the majority of review for me. I expect to continue releasing versions of this eBook as I get edits and feedback from various people – even after the final bundle is released. Don’t worry – you’ll get all updates as they are released!

 

 The interview series is also coming together very well! I have 5 interviews recorded and have the opening and closing slides designed. All 5 of the interviews are in the hands of my editor now, to make them extra-perfect. 

The interviews include, so far:

5 interviews

  • CQRS with Anders Ljusberg (Architect, Thomas Cook)
  • Design for Failure with Aria Stewart (from PayPal’s Kraken team)
  • RabbitMQ in Production with Carl Horberg (from CloudAMQP.com)
  • RabbitMQ Core and Community with Alvaro Videla (author of RabbitMQ in Action)
  • Workflow and Sagas with Jimmy Bogard (Chief Architect, Headspring)

I also have 2 more interviews either scheduled or waiting for confirmation. These additional guests include some incredibly well known developers in the messaging and architecture space, and I can’t wait to announce who they are!

In addition to the video versions of the interviews, I’m having every one of them transcribed in to full text. I will also provide the interviews as .mp3 files, giving you every opportunity to study the words and wisdom of these talented experts. Each transcription will have a brief summary, a list of links and information on how to get in touch with the guest and/or the company they represent. 

Availability Of RabbitMQ For Developers

All of these things listed above – and a few more things that I’m looking in to – will be available when the RabbitMQ For Developer bundle launches. Hopefully that will be happening in May, but it may be June.

However, there will be an opportunity for you to get all of this – and so much more – earlier than anyone else. Very soon, I will have a limited edition of the bundle available for sale, with early access to all of the content and more benefits than you could imagine… all of which will be in a single package:

RabbitMQ For Developers: The Mastermind Bundle

After getting a number of requests for consulting and other work surrounding RabbitMQ, I’ve decided to come out of semi-retirement on my consulting days, and offer a bundle of the RabbitMQ For Developers. This package will include direct consulting with me, and a few other benefits of very high value!

NewImage

The bundle will include:

  • A RabbitMQ consulting package from me
  • An invitation to a private Mastermind Developer group
  • An exclusive live webinar on RabbitMQ
  • And, early access to RabbitMQ For Developers
    • 12 Screencasts, 2.5 hours of content
    • My RabbitMQ Layout eBook
    • 6+ interviews with experts
    • Discounts on more books and services

With this full-service package, you will have early access to the complete RabbitMQ for Developers package and so much more!

You’ll get some one-on-one consulting from me, where I will review your existing RabbitMQ setup, or help you design an appropriate RabbitMQ layout for a new application.

You will also have ample opportunity to engage in meaningful discussion with the other Mastermind Developers, by joining a private discussion group.  

And you, along with the other Mastermind members, will be invited to an exclusive live webinar. You’ll have a chance to see how I solve a problems and keep my systems running at the same time, and have more opportunity to engage in a live Q&A session.

But you’ll have to hurry, once I make this package available.

This bundle will be strictly limited to only 10 seats! 

I only have so much time and attention available, and I want to make sure I can dedicate enough to you, directly. The more seats I open up, the less time I have to spend with you. So, I’m limiting the number of seats to 10. There will be no exceptions to this. Once they are gone, they are gone… and I may never offer a consulting package like this again.

Interested? Get Ready To Grab Your Seat

I haven’t yet made this Mastermind Bundle available, but I will soon – next week!

If you’re interested, you should get on my mailing list now. The list will have the first opportunity to take advantage of this one-time opportunity.

So get ready, get on the mailing list and get the first opportunity to join the RabbitMQ For Developers: Mastermind Bundle!

 

 

Join My List and Get Your Seat In This Bundle!

  

  

 

P.S. Expect the mastermind bundle to cost $1,200 (USD). It will be worth every penny! 

 

Categories: Blogs

"Command and Control"? I don't think that means what you think it means

I'm annoyed with the tendency for people to throw around the phrase "command and control" as shorthand for authoritarian command and control.

There are always "command and control" aspects when looking at leadership so it doesn't make sense to say "command and control leadership"

Command and control really refers to the establishing of intent or direction (aka command) and mechanisms for feedback to ensure intent is achieved or adjusted (aka control).  Understanding the need to address these aspects is quite important for effective leadership.

That there is command and control is not the problem but rather what kind of command and control is in play.  Authoritarian command and control is ineffective.  Mission command or David Marquet's leader-leader approach is effective.

I will accept though that the words "command" and "control" are predictably misleading for most people so perhaps it would be better to use another phrase like "intent and feedback".
Categories: Blogs

Minimal Viable UX

Xebia Blog - Wed, 05/06/2015 - 21:38

An approach to incorporate UX into the LEAN principle.

User Experience is often interpreted as a process where the ‘UX guru’ holds the ultimate truth in designing for an experience. The guru likes to keep control of his design and doesn’t want to feel less valuable when adopting advice from non-designers, where his concern is becoming a pixel pusher.

Adopting UX in a LEAN way, the feedback from team members minimizes the team going down the wrong path. This prevents the guru from perfecting a design where constraints over time will become clearer and less aligned with the customer needs. Interaction with the team speeds up development time by giving early insight.

Design for User Experience

UX has many different definitions, in the end it enables the user to perform a task with the help of an interface. All disciplines in a software development team should be aware of the user they are designing or developing for, starting in Sprint Zero. UX is not about setting up mockups, wireframes, prototypes and providing designs, it has to be part of the team culture where every team member can attribute to. We are trying to solve problems and problems are not being solved with design documentation but solved with efficient, elegant and sophisticated software.

How to get there

Create user awareness

Being aware of the user helps reduce waste and keeps you focused on things you should care about, functionality that adds value in the perception of the customer.

First, use a set of personas, put them on a wall and let your team members align those users with the functionality they are building. Developers can reflect functionality, interaction designers can optimize interface elements and visual designers can align styling with the user.

Second, use a customer journey map. This is a powerful tool. It helps in creating context, gives an overview of the user experience and helps to find gaps.

Prototype quickly

Prototyping becomes easier by the day, thanks to the amount and quality of tools out there. Prototyping can be performed by using paper, mockups (Balsamiq) or a web framework, such as FramerJS. Pick the type you prefer and which is suitable for the situation and has the appropriate depth.

Diagram of the iterative design and critique process. Warfel, Todd Zaki. 2009. Prototyping: A Practitioner’s Guide. New York: Rosenfeld Media.

Use small portions of prototypes and validate those with a minimal set of users. This helps you to deliver faster, therefore again eliminate waste and improves built-in quality. Iterative design helps you to amplify learning. KISS!

Communicate

Involved parties need to be convinced that what you are saying is based on business needs, the product and the people. You need to befriend and understand all involved parties in order to make it work across the board. Besides that, don’t forget your best friends, the users.

If you don't talk to your customers, how will you know how to talk to your customers? - Will Evans

Categories: Companies

Who the Heck Is “The Business”?

Leading Agile - Mike Cottmeyer - Wed, 05/06/2015 - 16:24

the business

As a VP of Technology your day is going along fine and then boom… priorities shift from product and marketing moves the date up. A big presser is now being formed and you have to adjust and communicate the change down to your teams to proceed forward. The following week, sales dials you up and announce that they have the trump card, $300k in sales are on the line. You have to stop what you are doing and get the release you were working on out of the door pronto. The teams below you are stuck at the perceived whim of a madman. Who is the madman they perceive? That “madman” is the variety of demands coming from Sales, Marketing, and the Product organization. It’s tough to prioritize in a way that makes everyone happy. So how can you handle this in your organization?

There are plenty of problems in organizations. Sometime plans don’t exist. Some people are in fact “yes-men”. There are 10 stakeholders. These, and plenty of other things, happen in the real world. And no, we can’t make everyone happy all of the time.

So when forming portfolio and program teams, the general sentiment of the crowd when I walk into the room to begin coaching is one of frustration. I repeatedly hear “the business” from anyone and everyone. It is truly a point of deflection, representative of years of abuse. The statement will come from all parts of the organization. Sales, marketing, IT, product, operations, no one is exempt. However…

After forming a proper portfolio team, the first thing to come out of a portfolio is a business-facing Epic. The portfolio will intentionally begin to prioritize work so that demand is focused on the next best thing. This is followed by another Epic, and another. They start prioritizing epics against each other and making credible, pragmatic business decisions around what they will do in the next few months. They begin to visualize a roadmap of epics. The roadmap will likely change and when it does, this group will have a way to prioritize those changes against the current plan. The biggest plus is that it is all transparent. The teams above, below, and around the portfolio will be informed. The voices are calm and the team is now dealing with the rational single voice of the portfolio.

This is called a forced prioritization. You are choosing which projects and epics the organization is focusing on in the next quarter and predicting the year. In a short time, the portfolio and teams that they coordinate can see that they are “the business”.

The post Who the Heck Is “The Business”? appeared first on LeadingAgile.

Categories: Blogs

Programming with kids & co-speaking with my son :)

Henrik Kniberg's blog - Wed, 05/06/2015 - 12:28

Yesterday me and Dave (11 yrs) spoke together for the first time! We did a public talk at Spotify about how to help kids learn to program. We’ve been experimenting a lot with that in my family (4 kids to experiment with… muahahaha), and wanted to share some learnings. Worked out better than we could have hoped, considering all the risky tech demos and live coding involved :)

Shared the stage with teacher Frida Monsén who talked about how to get this kind of stuff into schools. Thanks Helena Hjertén for organizing this, and Spotify for hosting & sponsoring. Here’s an article in Computer Sweden about this event and our little “mod club”.

Here are the slides! They are in Swedish though. Might do an English version of this talk some day :)

Dave on Stage

Dave demoing

Happy speakers

PS – here’s a short video about LearnToMod that I created earlier to show what it is all about.

Categories: Blogs

Python: Selecting certain indexes in an array

Mark Needham - Tue, 05/05/2015 - 23:39

A couple of days ago I was scrapping the UK parliament constituencies from Wikipedia in preparation for the Graph Connect hackathon and had got to the point where I had an array with one entry per column in the table.

2015 05 05 22 22 57

import requests
 
from bs4 import BeautifulSoup
from soupselect import select
 
page = open("constituencies.html", 'r')
soup = BeautifulSoup(page.read())
 
for row in select(soup, "table.wikitable tr"):
    if select(row, "th"):
        print [cell.text for cell in select(row, "th")]
 
    if select(row, "td"):
        print [cell.text for cell in select(row, "td")]
$ python blog.py
[u'Constituency', u'Electorate (2000)', u'Electorate (2010)', u'Largest Local Authority', u'Country of the UK']
[u'Aldershot', u'66,499', u'71,908', u'Hampshire', u'England']
[u'Aldridge-Brownhills', u'58,695', u'59,506', u'West Midlands', u'England']
[u'Altrincham and Sale West', u'69,605', u'72,008', u'Greater Manchester', u'England']
[u'Amber Valley', u'66,406', u'69,538', u'Derbyshire', u'England']
[u'Arundel and South Downs', u'71,203', u'76,697', u'West Sussex', u'England']
[u'Ashfield', u'74,674', u'77,049', u'Nottinghamshire', u'England']
[u'Ashford', u'72,501', u'81,947', u'Kent', u'England']
[u'Ashton-under-Lyne', u'67,334', u'68,553', u'Greater Manchester', u'England']
[u'Aylesbury', u'72,023', u'78,750', u'Buckinghamshire', u'England']
...

I wanted to get rid of the 2nd and 3rd columns (containing the electorates) from the array since those aren’t interesting to me as I have another source where I’ve got that data from.

I was struggling to do this but two different Stack Overflow questions came to the rescue with suggestions to use enumerate to get the index of each column and then add to the list comprehension to filter appropriately.

First we’ll look at the filtering on a simple example. Imagine we have a list of 5 people:

people = ["mark", "michael", "brian", "alistair", "jim"]

And we only want to keep the 1st, 4th and 5th people. We therefore only want to keep the values that exist in index positions 0,3 and 4 which we can do like this:

>>> [x[1] for x in enumerate(people) if x[0] in [0,3,4]]
['mark', 'alistair', 'jim']

Now let’s apply the same approach to our constituencies data set:

import requests
 
from bs4 import BeautifulSoup
from soupselect import select
 
page = open("constituencies.html", 'r')
soup = BeautifulSoup(page.read())
 
for row in select(soup, "table.wikitable tr"):
    if select(row, "th"):
        print [entry[1].text for entry in enumerate(select(row, "th")) if entry[0] in [0,3,4]]
 
    if select(row, "td"):
        print [entry[1].text for entry in enumerate(select(row, "td")) if entry[0] in [0,3,4]]
$ python blog.py
[u'Constituency', u'Largest Local Authority', u'Country of the UK']
[u'Aldershot', u'Hampshire', u'England']
[u'Aldridge-Brownhills', u'West Midlands', u'England']
[u'Altrincham and Sale West', u'Greater Manchester', u'England']
[u'Amber Valley', u'Derbyshire', u'England']
[u'Arundel and South Downs', u'West Sussex', u'England']
[u'Ashfield', u'Nottinghamshire', u'England']
[u'Ashford', u'Kent', u'England']
[u'Ashton-under-Lyne', u'Greater Manchester', u'England']
[u'Aylesbury', u'Buckinghamshire', u'England']
Categories: Blogs

All Team Quality Standards Should Be Part of the Definition of “Done”

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

The other day a technology leader was asking questions as if he didn’t agree that things like pair programming and code review should be part of the Definition of “Done” because they are activities that don’t show up in a tangible way in the end product. But if these things are part of your quality standards, they should be included in the definition of “Done” because they inform the “right way” of getting things done. In other words, the Definition of “Done” is not merely a description of the “Done” state but also the way(s) of getting to “Done” – the “how” in terms of quality standards. In fact, if you look at most of any team’s definition of “Done”, a lot of it is QA activity, carried out either as a practice or as an operation that is automated. Every agile engineering practice is essentially a quality standard and as they become part of a team’s practice, should be included as part of the definition of “Done”. The leader’s question was “if we’re done and we didn’t do pair programming and pair programming is part of our definition of “Done”, then does that mean we’re not done?” Which is sort of a backwards question because if you are saying you’re done and you haven’t done pair programming, then by definition pair programming isn’t part of your definition of done. But there are teams out there who would never imagine themselves to be done without pair programming because pair programming is a standard that they see as being essential to delivering quality product.

Everything that a Scrum Development Team does to ensure quality should be part of their definition of “Done”. The definition of “Done” isn’t just a description of the final “Done” state of an increment of product. In fact, If that were true, then we should be asking why anything is part of the definition of “Done”. This is the whole problem that this artifact solves. If this were the case, the team could just say that they are done whenever they say they are done and never actually identify better ways of getting to done and establishing better standards. We could just say (and we did and still do), “there’s the software, it’s done,” the software itself being its own definition of “Done”.

On the contrary the definition of “Done” is what it means for something to be done properly. In other words, it is the artifact that captures the “better ways of developing software” that the team has uncovered and established as practice because their practices reflect their belief that “Continuous attention to technical excellence and good design enhances agility” (Manifesto for Agile Software Development). The definition of “Done” is essentially about integrity—what is done every Sprint in order to be Agile and get things done better. When we say that testing is part of our definition of “Done”, that is our way of saying that as a team we have a shared understanding that it is better to test something before we say that it is done than to say that it’s done without testing it because without testing it we are not confident that it is done to our standards of quality. Otherwise, we would be content in just writing a bunch of code, seeing that it “works” on a workstation or in the development environment and pushing it into production as a “Done” feature with a high chance that there are a bunch of bugs or that it may even break the build.

This is similar to saying a building is “Done” without an inspection (activity/practice) that it meets certain safety standards or for a surgeon to say that he or she has done a good enough job of performing a surgical operation without monitoring the vital signs of the patient (partly automated, partly a human activity). Of course, this is false. The same logic holds true when we add other activities (automated or otherwise) that reflect more stringent quality standards around our products. The definition of “Done”,therefore, is partly made up of a set of activities that make up the standard quality practices of a team.

Professions have standards. For example, it is a standard practice for a surgeon to wash his or her hands between performing surgical operations. At one time it wasn’t. Much like TDD or pair programming, it was discovered as a better way to get a job done. In this day and age, we would not say that a surgeon had done a good job if he or she failed to carry out this standard practice. It would be considered preposterous for someone to say that they don’t care whether or not surgeons wash their hands between operations as long as the results are good. If a dying patient said to a surgeon, “don’t waste time washing your hands just cut me open and get right to it,” of course this would be dismissed as an untenable request. Regardless of whether or not the results of the surgery were satisfactory to the patient, we would consider it preposterous that a surgeon would not wash his or her hands because we know that this is statistically extremely risky, even criminal behaviour. We just know better. Hand washing was discovered, recognized as a better way of working, formalized as a standard and is now understood by even the least knowledgable members of society as an obvious part of the definition of “Done” of surgery. Similarly, there are some teams that would not push anything to production without TDD and automated tests. This is a quality standard and is therefore part of their definition of “Done”, because they understand that manual testing alone is extremely risky. And then there are some teams with standards that would make it unthinkable for them to push a feature that has not been developed with pair programming. For these teams, pair programming is a quality standard practice and therefore part of their definition of “Done”.

“As Scrum Teams mature,” reads the Scrum Guide, “it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality.” What else is pair programming, or any other agile engineering practice, if it is not a part of a team’s criteria for higher quality? Is pair programming not a more stringent criteria than, say, traditional code review? Therefore, any standard, be it a practice or an automated operation, that exists as part of the criteria for higher quality should be included as part of the definition of “Done”. If it’s not part of what it means for an increment of product to be “Done”—that is “done right”—then why are you doing it?

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

Lineup of 2015 Agile Executive Forum Announced

Scrum Expert - Tue, 05/05/2015 - 18:11
The Agile Alliance has announced the final speaker lineup for the 2015 Agile Executive Forum, which will be held this year on August 3 at the Center for Innovative Technology in Herndon, Virginia. This annual event will bring together some of the world’s top executives to explore the latest in strategic thinking in Lean and Agile practices and principles applied towards building the Lean Enterprise. “At the 2015 Agile Executive Forum, we’re excited about both building on past events and extending into the future of Agile,” said Sanjiv Augustine, Agile Executive ...
Categories: Communities

Redesigned PlanningPoker.com Launched

Scrum Expert - Tue, 05/05/2015 - 17:34
352 Inc. has announced a fully redesigned and rebuilt Planning Poker for the agile development community. Initially built by Mountain Goat Software and now redesigned by 352 Inc., the new PlanningPoker.com reimagines the classic planning tool for today’s agile teams. 352’s team updated the digital product with an effortless user experience and modern design, speeding up the the estimation process and offering an unmatched experience for scrum teams. For more than a decade, planning poker has been used to streamline effort pointing and sprint planning, and the new PlanningPoker.com introduces new ...
Categories: Communities

CQRS with MediatR and AutoMapper

Jimmy Bogard - Tue, 05/05/2015 - 17:15

CQRS is a simple pattern – two objects for command/queries where once there was one. These days just about every system I build utilizes CQRS, as it’s a natural progression from refactoring your apps around the patterns arising from reads and writes. I’ve been refactoring a Microsoft sample app to techniques I use on my apps (mainly because I want something public to look at for new projects) at my github.

Remember, CQRS is not an architecture, it’s a pattern, which makes it very easy to introduce into your applications. You can use CQRS in some, most, or all of your application and it’s easy to move towards or away from.

Even in simple apps, I like to keep my read models separate from my write models, mainly because the demands for each are drastically different. Since CQRS is just a pattern, we can introduce it just by refactoring.

First, let’s look at refactoring a complex GET/read scenario.

Read model

My initial controller action for a complex read is…well, complex:

public ViewResult Index(string sortOrder, string currentFilter, string searchString, int? page)
{
    ViewBag.CurrentSort = sortOrder;
    ViewBag.NameSortParm = String.IsNullOrEmpty(sortOrder) ? "name_desc" : "";
    ViewBag.DateSortParm = sortOrder == "Date" ? "date_desc" : "Date";

    if (searchString != null)
    {
        page = 1;
    }
    else
    {
        searchString = currentFilter;
    }

    ViewBag.CurrentFilter = searchString;

    var students = from s in db.Students
                   select s;
    if (!String.IsNullOrEmpty(searchString))
    {
        students = students.Where(s => s.LastName.ToUpper().Contains(searchString.ToUpper())
                               || s.FirstMidName.ToUpper().Contains(searchString.ToUpper()));
    }
    switch (sortOrder)
    {
        case "name_desc":
            students = students.OrderByDescending(s => s.LastName);
            break;
        case "Date":
            students = students.OrderBy(s => s.EnrollmentDate);
            break;
        case "date_desc":
            students = students.OrderByDescending(s => s.EnrollmentDate);
            break;
        default:  // Name ascending 
            students = students.OrderBy(s => s.LastName);
            break;
    }

    int pageSize = 3;
    int pageNumber = (page ?? 1);
    return View(students.ToPagedList(pageNumber, pageSize));
}

In order to derive our read models, I center around building query objects and result objects. The Query model represents the “inputs” to the query and the Result model represents the “outputs” from the query. This also fits very well into the “one-model-in-one-model-out” concept I use in my apps these days.

Looking at our controller, the inputs are pretty obvious – it’s the parameters to the controller action!

public class Index
{
    public class Query : IRequest<Result>
    {
        public string SortOrder { get; set; }
        public string CurrentFilter { get; set; }
        public string SearchString { get; set; }
        public int? Page { get; set; }
    }

To make my life easier with this pattern, I’ll use MediatR as a simple means of providing a way to have “one model in goes to something to get one model out” without creating bloated service layers. Uniform interfaces are great!

The next piece I need are the output – the result. I take *all* the results, including those “ViewBag” pieces as the Result object from my query:

public class Result
{
    public string CurrentSort { get; set; }
    public string NameSortParm { get; set; }
    public string DateSortParm { get; set; }
    public string CurrentFilter { get; set; }
    public string SearchString { get; set; }

    public IPagedList<Model> Results { get; set; }
}

public class Model
{
    public int ID { get; set; }
    [Display(Name = "First Name")]
    public string FirstMidName { get; set; }
    public string LastName { get; set; }
    public DateTime EnrollmentDate { get; set; }
}

Finally, I take the inside part of that controller action and place it in a handler that takes in a Query and returns a Result:

public class QueryHandler : IRequestHandler<Query, Result>
{
    private readonly SchoolContext _db;

    public QueryHandler(SchoolContext db)
    {
        _db = db;
    }

    public Result Handle(Query message)
    {
        var model = new Result
        {
            CurrentSort = message.SortOrder,
            NameSortParm = String.IsNullOrEmpty(message.SortOrder) ? "name_desc" : "",
            DateSortParm = message.SortOrder == "Date" ? "date_desc" : "Date",
        };

        if (message.SearchString != null)
        {
            message.Page = 1;
        }
        else
        {
            message.SearchString = message.CurrentFilter;
        }

        model.CurrentFilter = message.SearchString;
        model.SearchString = message.SearchString;

        var students = from s in _db.Students
                       select s;
        if (!String.IsNullOrEmpty(message.SearchString))
        {
            students = students.Where(s => s.LastName.Contains(message.SearchString)
                                           || s.FirstMidName.Contains(message.SearchString));
        }
        switch (message.SortOrder)
        {
            case "name_desc":
                students = students.OrderByDescending(s => s.LastName);
                break;
            case "Date":
                students = students.OrderBy(s => s.EnrollmentDate);
                break;
            case "date_desc":
                students = students.OrderByDescending(s => s.EnrollmentDate);
                break;
            default: // Name ascending 
                students = students.OrderBy(s => s.LastName);
                break;
        }

        int pageSize = 3;
        int pageNumber = (message.Page ?? 1);
        model.Results = students.ProjectToPagedList<Model>(pageNumber, pageSize);

        return model;
    }
}

My handler now completely encapsulates the work to take the input and build the output, making it very easy to test the logic of my system. I can refactor the contents of this handler as much as I want and the external interface remains input/output. In fact, if I wanted to make this a view or stored procedure, my input/output and tests don’t change at all!

One slight change was to switch to AutoMapper projection at the bottom with the ProjectToPagedList method:

public static class MapperExtensions
{
    public static async Task<List<TDestination>> ProjectToListAsync<TDestination>(this IQueryable queryable)
    {
        return await queryable.ProjectTo<TDestination>().DecompileAsync().ToListAsync();
    }

    public static IQueryable<TDestination> ProjectToQueryable<TDestination>(this IQueryable queryable)
    {
        return queryable.ProjectTo<TDestination>().Decompile();
    }

    public static IPagedList<TDestination> ProjectToPagedList<TDestination>(this IQueryable queryable, int pageNumber, int pageSize)
    {
        return queryable.ProjectTo<TDestination>().Decompile().ToPagedList(pageNumber, pageSize);
    }

    public static async Task<TDestination> ProjectToSingleOrDefaultAsync<TDestination>(this IQueryable queryable)
    {
        return await queryable.ProjectTo<TDestination>().DecompileAsync().SingleOrDefaultAsync();
    }
}

I build a few helper methods to project from a queryable to my read model. The AutoMapper projections completely bypass my write model and craft a query that only reads in the information I need for this screen:

exec sp_executesql N'SELECT 
    [Project1].[C1] AS [C1], 
    [Project1].[ID] AS [ID], 
    [Project1].[LastName] AS [LastName], 
    [Project1].[FirstName] AS [FirstName], 
    [Project1].[EnrollmentDate] AS [EnrollmentDate]
    FROM ( SELECT 
        [Extent1].[ID] AS [ID], 
        [Extent1].[LastName] AS [LastName], 
        [Extent1].[FirstName] AS [FirstName], 
        [Extent1].[EnrollmentDate] AS [EnrollmentDate], 
        ''0X0X'' AS [C1]
        FROM [dbo].[Person] AS [Extent1]
        WHERE ([Extent1].[Discriminator] = N''Student'') AND ((( CAST(CHARINDEX(UPPER(@p__linq__0), UPPER([Extent1].[LastName])) AS int)) > 0) OR (( CAST(CHARINDEX(UPPER(@p__linq__1), UPPER([Extent1].[FirstName])) AS int)) > 0))
    )  AS [Project1]
    ORDER BY [Project1].[LastName] ASC
    OFFSET 3 ROWS FETCH NEXT 3 ROWS ONLY ',N'@p__linq__0 nvarchar(4000),@p__linq__1 nvarchar(4000)',@p__linq__0=N'a',@p__linq__1=N'a'

Some folks prefer to create SQL Views for their “Read” models, but that seems like a lot of work. AutoMapper projections have the same concept of a SQL View, except it’s defined as a projected C# class instead of a SQL statement with joins. The result is the same, except I now define the projection once (in my read model) instead of twice in my model and in a SQL view.

My controller action becomes quite a bit slimmed down as a result:

public ViewResult Index(Index.Query query)
{
    var model = _mediator.Send(query);

    return View(model);
}

Slimmed down to the point where my controller action is really just a placeholder for defining a route (though helpful when my actions do more interesting things like Toastr popups etc).

Now that we’ve handled reads, what about writes?

Write models

Write models tend to be a bit easier, however, many of my write models tend to have a read component to them. The page with the form of data is still a GET, even if it’s followed by a POST. This means that I have some duality between GET/POST actions, and they’re a bit intertwined. That’s OK – I can still handle that with MediatR. First, let’s look at what we’re trying to refactor:

public ActionResult Edit(int? id)
{
    if (id == null)
    {
        return new HttpStatusCodeResult(HttpStatusCode.BadRequest);
    }
    Student student = db.Students.Find(id);
    if (student == null)
    {
        return HttpNotFound();
    }
    return View(student);
}

[HttpPost]
[ValidateAntiForgeryToken]
public ActionResult Edit([Bind(Include = "ID, LastName, FirstMidName, EnrollmentDate")]Student student)
{
    try
    {
        if (ModelState.IsValid)
        {
            db.Entry(student).State = EntityState.Modified;
            db.SaveChanges();
            return RedirectToAction("Index");
        }
    }
    catch (RetryLimitExceededException /* dex */)
    {
        //Log the error (uncomment dex variable name and add a line here to write a log.
        ModelState.AddModelError("", "Unable to save changes. Try again, and if the problem persists see your system administrator.");
    }
    return View(student);
}

Ah, the notorious “Bind” attribute with magical request binding to entities. Let’s not do that. First, I need to build the models for the GET side, knowing that the result is going to be my command. I create an input for the GET action with the POST model being my result:

public class Query : IAsyncRequest<Command>
{
    public int? Id { get; set; }
}

public class QueryValidator : AbstractValidator<Query>
{
    public QueryValidator()
    {
        RuleFor(m => m.Id).NotNull();
    }
}

public class Command : IAsyncRequest
{
    public int ID { get; set; }
    public string LastName { get; set; }

    [Display(Name = "First Name")]
    public string FirstMidName { get; set; }

    public DateTime? EnrollmentDate { get; set; }
}

One nice side effect of building around queries/commands is it’s easy to layer on tools like FluentValidation. The command itself is based on exactly what information is needed to process the command, and nothing more. My views are built around this model, projected from the database as needed:

public class QueryHandler : IAsyncRequestHandler<Query, Command>
{
    private readonly SchoolContext _db;

    public QueryHandler(SchoolContext db)
    {
        _db = db;
    }

    public async Task<Command> Handle(Query message)
    {
        return await _db.Students
            .Where(s => s.ID == message.Id)
            .ProjectToSingleOrDefaultAsync<Command>();
    }
}

Again, I skip the write model and go straight to SQL to project to my write model’s read side.

Finally, for the POST, I just need to build out the handler for the command:

public class CommandHandler : AsyncRequestHandler<Command>
{
    private readonly SchoolContext _db;

    public CommandHandler(SchoolContext db)
    {
        _db = db;
    }

    protected override async Task HandleCore(Command message)
    {
        var student = await _db.Students.FindAsync(message.ID);

        Mapper.Map(message, student);
    }
}

Okay so this command handler is very, very simple. Simple enough I can use AutoMapper to map values back in. Most of the time in my systems, they’re not so simple. Approving invoices, notifying downstream systems, keeping invariants satisfied. Unfortunately Contoso University is a simple application, but I could have something more complex like updating course credits:

public class CommandHandler : IAsyncRequestHandler<Command, int>
{
    private readonly SchoolContext _db;
 
    public CommandHandler(SchoolContext db)
    {
        _db = db;
    }
 
    public async Task<int> HandleCore(Command message)
    {
        var rowsAffected = await _db.Database
            .ExecuteSqlCommandAsync("UPDATE Course SET Credits = Credits * {0}", message.Multiplier);
 
        return rowsAffected;
    }
}

I have no idea why I’d need to do this action, but you get the idea. However complex my write side becomes, it’s scoped to this. In fact, I can often refactor my domain model to handle its own command handling:

public class CommandHandler : AsyncRequestHandler<Command>
{
    private readonly SchoolContext _db;
 
    public CommandHandler(SchoolContext db)
    {
        _db = db;
    }
 
    protected override async Task HandleCore(Command message)
    {
        var student = await _db.Students.FindAsync(message.ID);
 
        student.Handle(message);
    }
}

All the logic in processing the command is inside my domain model, fully encapsulated and unit-testable. My handler just acts as a means to get the domain model out of the persistent store. The advantage to my command handler now is that I can refactor towards a fully encapsulated, behavioral domain model without changing anything else in my application. My controller is none the wiser:

public async Task<ActionResult> Edit(Edit.Query query)
{
    var model = await _mediator.SendAsync(query);

    return View(model);
}

[HttpPost]
[ValidateAntiForgeryToken]
public async Task<ActionResult> Edit(Edit.Command command)
{
    await _mediator.SendAsync(command);

    return this.RedirectToActionJson(c => c.Index(null));
}

That’s why I don’t worry too much about behavioral models up front – it’s just a refactoring exercise when I see code smells pop up inside my command handlers. When command handlers get gnarly (NOT BEFORE), just push the behavior down to the domain objects as needed using decades-old refactoring techniques.

That’s it! MediatR and AutoMapper together to help refactor towards CQRS, encapsulating logic and behavior together into command/query objects and handlers. Our domain model on the read side merely becomes a means to derive projections, just as Views are means to build SQL projections. We have a common interface with one model in, one model out to center around and any cross-cutting concerns like validation can be defined around those models.

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

Categories: Blogs

Teams, Backlogs, Working Tested Software

Leading Agile - Mike Cottmeyer - Tue, 05/05/2015 - 17:09

I think there is a lot of noise in our system right now. Lot’s of methods to consider. Lot’s of ways to do agile. At the end of the day… for me, for LeadingAgile… it comes down to three things.

Can you form teams, do those teams have an actionable backlog, are those teams able to produce a working tested increment at the end of a predetermined time interval?

Do the teams have the means to hold themselves accountable, do they have clarity around what to build, can they measure progress against a known outcome?

Do the teams have the autonomy to get the job done, do they have a meaningful purpose to build toward, can they demonstrate mastery of their craft?

Teams, backlogs, working tested software

Accountability, clarity, measurable progress

Autonomy, purpose, mastery

All the same stuff, just said three different ways. Honestly, I don’t care what method you choose, but if we ever talk and you tell me you are doing agile, those are the three conditions I’m going to test for.

Furthermore, these are the only three conditions an executive must test for to know if their organization is on the right track with agile. Failure in any of these three and you aren’t doing it right, period.

The post Teams, Backlogs, Working Tested Software appeared first on LeadingAgile.

Categories: Blogs

Impact-Driven Scrum

Scrum Expert - Tue, 05/05/2015 - 15:30
One of the important concept around Agile and Scrum is that it is more important to build the right product than to build the product right. Impact Management is a framework that helps managers to focus on impact of an idea and a product. In her article “Impact-Driven Scrum Delivery”, Ingrid Domingues explains how to brings together Scrum and Impact Management in software development projects where design is important. Impact Management is based on Impact Mapping that provides the ability to define expected impact for business and users in a model, ...
Categories: Communities

SoCraTes UK, Worcestershire, UK, June 4-7

Scrum Expert - Tue, 05/05/2015 - 15:13
SoCraTes is an International Software Craftsmanship retreat for open-minded craftspeople who want to improve their craft and the software industry as a whole. It’s a great opportunity to speak to and code with many like-minded and talented developers. The conference itself is free. SoCraTes UK, the International Software Craftsmanship retreat follows the open space format for conferences. Open space is a simple methodology for self-organizing conference tracks. It relies on participation by people who have a passion for the topics to be discussed. There is no preplanned list of topics, only ...
Categories: Communities

Tips for CST Aspirants

Scrum Breakfast - Tue, 05/05/2015 - 14:14
So you want to become a Certified Scrum Trainer? What does it take to become a CST? I facilitated a workshop at the Phoenix Scrum Gathering (#SGPHX) on the challenges of becoming a trainer. Several people shared their experiences, including current and former members of the TAC (Trainer Acceptance Committee) and Tirell Payton, a Certified Scrum Coach whose first attempt at passing the TAC was not successful. 
Tirell wrote the following summary, which I thankfully quote:

During the retreat Peter Stevens facilitated a session on the CST process and some of the potential pitfalls the aspirants encounter as they go through the process.

I acted as the scribe and town crier, and as such lots of people have come up and asked me for my list of items.  The items on the list follow 2 key dimensions:  The common items that lead to candidates not being accepted and advice for how to make it through the process with your sanity intact.

For those of you on the list, hopefully these items will be helpful to anyone you're mentoring through the process.  Tomorrow at the gathering if anyone has any questions on these items, I am willing to give advice and share my experiences.

Some of the items that are a challenge for applicants:
  • Knowledge.  Know your stuff backward and forward.  Even better, be able to communicate it clearly and succinctly
  • Community Involvement.  The TAC really likes to see a breadth of community involvement
  • In person techniques.  Context matters, be mindful of the fact that when you are in front of the TAC review, some techniques that work very well in the context of a 2 day training course may not work well at all in your TAC panel session.
  • Personal Statement.  The TAC wants to understand how you will make an impact as a trainer. Becoming a CST is just as much an affirmation of your passion and commitment as well as a platform for you to go on to greater heights.  How will you change people's lives in 2 days?
  • Co Training.  The TAC wants to see very good evidence that you have co-trained with CSTs.  Yes its difficult, yes its hard to coordinate schedules, but its very worthwhile.  Co-training depends your connection with your training community, spreads effective techniques, and provides an opportunity to observe stylistic differences.

Some of the advice from the session:
  • Don't give up.  If you don't get through on the first try, understand you are not the first person that this has happened to.  
  • Be accepting of feedback.  Listen.
  • Treat it like a job interview with the same level of professional discipline and focus
  • Ask and ye shall receive.  Make yourself visible in the community.  Help.  Enlist others to be co-conspirators in your success.
Categories: Blogs

Traditional Risk Management on Agile Projects

Leading Agile - Mike Cottmeyer - Tue, 05/05/2015 - 10:00

Worry_dolls

In the Agile classes that I teach, there are often participants who undergo mental, emotional and (sometimes) physical discomfort at the thought of letting go of the old way of doing things. The symptoms are obvious. Some fight back with questions that seek permission to skip a rule or two. Some keep trying to redefine Agile in a way that turns it back into waterfall and some just sit there, making the kind of faces people make when they are having digestive issues.

Here is the thing…you don’t have to throw all of it away. There are some bits that are definitely worth keeping. The trick is knowing which ones are which.

In my practice of Agile, which is mostly centered around Scrum, one of the traditional practices I find continues to have value is traditional Risk Management.

When I am working with teams I typically schedule a Risk Management meeting that will be held at the same time, in the same place, on the same day, every week. When the project is starting up, I make a big deal about it and push hard to get management involved. I specifically present it as a traditional project management tool that I want to include in our practice of Agile. And then I beg, I plead, I bribe them with food… whatever it takes to get them in the room.

During the initial meeting I spend time explaining the differences between risks (things that might happen) and issues (things that have happened). I explain that in this weekly meeting we will discover risks, explore their potential impact, prioritize them and plan a response. I show them a risk register, present an example to demonstrate how it works and how we will use it to track and monitor risk throughout the life of the project. I explain that the risk meeting will be held each week for the duration of the project and that their participation is vital to the success of the project and that I will be present for the meeting each week whether anyone else attends or not.

Then we hand out post-its and everyone begins identifying the things they are worried about. The only rule is that we are focused on finding, not solving. We collect them all, sort them, remove duplicates, establish themes we want to use to categorize them and begin our intial prioritization. This is the beginning of our Risk Register, which is basically just a big backlog of risks.

Then, one by one, we talk through the risks, entering data into the fields as we move across the row. Often times, talking about a risk will generate a bunch of new risks… which is a good thing. As we work through probability and impact analysis of each risk, we often find that priority will shift. Also a good thing.

If you’d like to check it out, here is a Risk Register Sample. It includes an explanation of each field.

Having the Risk Register is a great way to capture and monitor things that might creep up and bite us as we work through the project. It’s a good thing to have. But that is not the only reason I include this traditional project management practice on my Agile projects. Most of the projects I get to work on are in organizations that include a mix of traditional and Agile. Often times, these organizations are in the early stages of Agile transition. So, in addition to the normal stress of a project, we now have the added complexity that comes from introducing a new way or working as well as management, who may not entirely understand all the ways that Agile will impact them and the data they receive about projects. In short.. lots of stress. Stress is way bad. Stress results in poor decision making, panic and worst of all leadership who feel they need to step in and (gulp) “help” the people doing the work.

Actually documenting, evaluating and planning for all the things that might go wrong is a great way to plan for the rainy days we are going to encounter. If any of those risks evolve into issues, we’ve got a plan. Many of them won’t, and that is okay. The time spent talking about them is not waste if the discussion frees up our minds so that we can be more focused on the things we didn’t think of that crop up along the way.

What I have found though, is that one of the reasons this meeting is so important is that it gives the people who worry about the project a place to come put those worries down. Once they realize that by bringing it up in this meeting, it will be thoroughly considered, planned for and monitored, the stress, by and large, disappears. Having a place where people can unburden themselves of the things that worry them can go a long way towards freeing them up to stay focused on the work that leads to shippable product.

The post Traditional Risk Management on Agile Projects appeared first on LeadingAgile.

Categories: Blogs

Stop following the successful companies

Agile World - Venkatesh Krishnamurthy - Mon, 05/04/2015 - 20:00

It is a common practice to look at successful people and learn the “best practices” as much as possible. The belief is that, by copying the successful practices, we become successful as well. My question is, does that really work ?   Can you become successful investor like Warren Buffet by reading every article/book written about him?

Even many organizations are obsessed trying to copy the practices from Google, Facebook, Amazon, etc. There is nothing wrong with it. However, I believe that one could learn more from failures than successes. So, focusing on the stories from failed companies would be more valuable than popular/successful companies.

clip_image001clip_image002

There are couple of other reasons why I believe it is time to stop following successful companies:

1. Successful companies became so while they learned from many failures during their journey. Each failure would have enabled them to build some kind of structure to support from future failures and making them resilient. The media in turn focuses only on the “final” state of the company rather than the journey.

One would never get a chance to understand the “resilient structure” that has been built in place to withstand failures.  That’s why, copying only the “practices” from the final state without having a proper resilient structure in place will cripple companies even with a small tremor.

2. There is always a third dimension that you would never get to see.  In another research, the scientists found a pattern of increase in ice cream sales to increase in deaths due to drowning. They were baffled until they realized the 3rd dimension to this data/research.

The ice cream sales increased mostly during the summer, and this is the time where most kids would like to relax and enjoy swimming in rivers/pools as compared to winter months. This increase in swimming proportionality increased the fatalities as well.  As a researcher, if you ignore the 3rd dimension, in this case, the seasonal impact on ice cream sales, one would end up banning the ice creams.

Similarly, the success of every organization would involve some kind of 3rd dimension which is difficult to know/understand. Trying to copy simply the practices could be more harmful than helpful.

Toyota is my favorite example. 1000s of books have been written about Toyota Production system, Lean thinking, etc. Even Toyota allows people to visit their factories and learn from them. The question is, can you become like Toyota by copying their practices?   One would never be able to replicate Toyota or any other successful company. The success comes only from learning that typically happens through failures.  One should try to build their own set of practices based on their context/experiences.

That is; it is very important for organizations to build safe to fail and fail-fast/fail-often culture.

Going forward, start chasing the stories from failed companies and stop following the successful/popular companies.

Categories: Blogs

Slicing and Dicing User Stories

Scrum Expert - Mon, 05/04/2015 - 17:50
Most agile software development team grapple with user stories as a technique for understanding what needs to be developed iteratively. This talk presents some techniques for uncovering useful user stories and how to slice them in a way to deliver value in small increments. Video producer: http://agileadria.com/
Categories: Communities

Knowledge Sharing


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