Skip to content

Feed aggregator

ATDD Topics

NetObjectives - Wed, 07/20/2016 - 11:52
I've written about several ATDD topics recently on the ATDD website.  Here's a summary of the topics: Testing Contracts for Services There is a growing use of services and micro-services to develop applications. I’ve had numerous questions about how to test the services and who should be responsible for what testing. I wrote a book called Interface-Oriented Design which covered many of these...

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

Case Study: ATDD - A Critical Success Factor

NetObjectives - Wed, 07/20/2016 - 09:42
At a financial firm where I taught and coached ATDD and TDD, here’s the results as reported by one team: “One of the critical success factors for our project was our adoption of ATTD and TDD, including frequent test collaboration, engaging the business in writing acceptance test criteria, and robust test automation.” “Collaborating on writing tests ensured that the entire team understood all...

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

Extended Call for GOAT 2016 Speakers

Notes from a Tool User - Mark Levison - Tue, 07/19/2016 - 23:32

Gatineau Ottawa Agile Tour 2016
The Gatineau Ottawa Agile Tour 2016 will take place on November 21st and, once again, anyone with Agile experience is welcome to propose a session for the conference. The deadline for submissions for speakers has been extended to Thursday, September 15th, 2016, to better accommodate those who are travelling or on Summer vacation.

Would you like to present a case study or a report on your experience implementing Lean or Agile within your business or workplace? Have you discovered a workshop so useful that you would like to share it with others? Would you like to take the opportunity to share your knowledge on Lean or Agile? If you answered yes to one of these, we would definitely love to hear what you have to offer!

Submit your session proposal here now!
https://confengine.com/gatineau-ottawa-agile-tour-2016

We encourage you to not only learn more about this upcoming opportunity to participate in the value-packed conference, but to Join/Share/Attend the following pages to lend your support and spread the word.

2016 Gatineau Ottawa Agile Tour Facebook Event

Agile Ottawa Facebook Group

Extended Call for Speakers for the Gatineau Ottawa Agile Tour 2016

 

Image attribution: http://goagiletour.ca/

Categories: Blogs

Prolongation de l’appel aux conférenciers pour la tournée agile de l’Outaouais (GOAT) 2016

Agile Ottawa - Tue, 07/19/2016 - 21:44
Nous avons déjà reçu d’excellentes propositions de conférences pour GOAT 2016, merci à tous ceux qui ont pris le temps de les soumettre. L’été s’est enfin installé, et quelle chaleur! Nous avons réalisé que, même si vous vouliezsoumettre une conférence, vous … Continue reading →
Categories: Communities

MediatR Extensions for Microsoft Dependency Injection Released

Jimmy Bogard - Tue, 07/19/2016 - 21:07

To help those building applications using the new Microsoft DI libraries (used in Orleans, ASP.NET Core, etc.), I pushed out a helper package to register all of your MediatR handlers into the container.

MediatR.Extensions.Microsoft.DependencyInjection

To use, just add the AddMediatR method to wherever you have your service configuration at startup:

public void ConfigureServices(IServiceCollection services)
{
  services.AddMvc();

  services.AddMediatR(typeof(Startup));
}

You can either pass in the assemblies where your handlers are, or you can pass in Type objects from assemblies where those handlers reside. The extension will add the IMediator interface to your services, all handlers, and the correct delegate factories to load up handlers. Then in your controller, you can just use an IMediator dependency:

public class HomeController : Controller
{
  private readonly IMediator _mediator;

  public HomeController(IMediator mediator)
  {
    _mediator = mediator;
  }
  public IActionResult Index()
  {
    var pong = _mediator.Send(new Ping {Value = "Ping"});
    return View(pong);
  }
}

And you’re good to go. Enjoy!

Categories: Blogs

Software Craftsmanship as an Act of Courage

BigVisible Solutions :: An Agile Company - Tue, 07/19/2016 - 19:00

Skydiving 

Agile is Dead (Long Live Agility)” – Dave Thomas.

A great quote, if ever I heard one. If you haven’t read or listened to Dave Thomas before, then I highly recommend his discussions on the subject of agility, and not “Agile”. For example, in this video from GOTO 2015.

For my part, I agree with much of Dave’s perspective. Here are some facts:

  • Waterfall, RUP, and Agile were all conceived as engineering processes for software development.
  • All of them are processes (journeys) and none of them guarantee end results.
  • You cannot buy, sell, or give someone agile.
  • You can teach agile concepts, and demonstrate some circumstances in which to apply those concepts.
  • We want software to do complex things, but we want a simple way to describe, develop, and validate.

Dave believes that at the root of the problem is the fact that Agile has been turned into a noun (with a big A), something that can be given to someone or put on top of something else. But previously agile (small a) was just an adjective meaning “able to move quickly and easily”. “Agile software development” therefore was simply a process for developing software “quickly and easily”. Today Agile has come to mean much more than that, though the goal is still to deliver software (and other products) quickly and easily. It isn’t now, nor was it ever designed to be, something (a noun) that you add to an existing development process to “solve” delivery problems. To become agile in the delivery sense (that is, “able to move quickly and easily”), you have to put in the work, just like you would have to in order to become physically agile.

Ok, so how do I know I’m going to get the software I wanted, if there aren’t guarantees? The Agile Transformation Movement does more than any previous methodology to answer that question. However, some of those selling “agile” don’t cover this area enough or, worse, get fixated on a single implementation recommendation (co-location, for example). A broader view has to be considered and addressed.

Practice Your Craft

Software development and IT operations are about creating specific solutions to different problems. Unless all companies, governments, not-for-profits and individuals use the exact same software for the exact same purposes without exception (an end that I cannot foresee occurring anytime soon), we need to look at the practice of software development and technology operations. This doesn’t mean you should outsource all of your software development and technology operations: often times there is a direct conflict between your goals and those of a service provider. This doesn’t mean you have to build everything internally, either; that’s just not practical. It does mean that the quality you want should correspond to the effort you put into getting that quality. All applications are developed to be used, either by people or other programs. Therefore by definition software is a foundation. The question is: is the software you are creating cement or quicksand? High-quality software requires high-quality development by developers who know their craft.

High-quality software requires high-quality development by devs who know their craft
Click To Tweet

These developers focus on developing a rock-solid foundation that users can build upon without fear of shoddy architecture. Today few people take this perspective, assuming that developers wouldn’t knowingly create a buggy product, or that developers that do take this perspective are somehow less productive, and therefore less valuable. The unfortunate truth is that, if current software were buildings, many wouldn’t pass code.

Return on Team as a “Guarantee”

“Any book that tells you, ‘This is how to build software,’ is wrong. Because, unless that book was written for your team and your company doing your project at this particular time, it doesn’t know how you should write software.” – Dave Thomas

Software development and software operations are crafts, practiced at varying levels, by a huge number of people of different skills and capabilities. What’s important, however, is that these crafts are best practiced by teams. The best teams are those that grow together with each member improving his or her contribution to their craft in concert with the skills of the rest of their team. Members of high-performance teams cultivate complementary skills so that the team product is greater than any individual member could produce alone. A persistent, agility-focused team grows according to their needs, abilities, and personalities. “One size fits all” won’t work here. As Dave Thomas said in his GOTO 2015 session:

“Any book that tells you, ‘This is how to build software,’ is wrong. Because, unless that book was written for your team and your company doing your project at this particular time, it doesn’t know how you should write software.”

Recently, a colleague of mine, Brent Barton, wrote about a relatively novel concept in his blog post “Using Return on Team to Enhance Business Agility”. Anyone even casually acquainted with the concept of Return on Investment (ROI) should be able to grasp Return on Team without difficulty: persistent teams, by virtue of growing together and in complementary fashion, are able to more accurately estimate their throughput and, better, their outcomes than new or newly formed teams. If the team knows the capabilities of itself as a collective and of each individual member, made possible by spending lots of time together delivering value in many different projects, then they can—if they are so inclined—offer the “guarantee” of quality and speed that businesses are looking for. Either way, changing your teams up every time you have a new project only makes estimating outcomes that much harder.

Want a software delivery guarantee? Invest in persistent Agile teams.
Click To Tweet

If you need software built and operated to meet a specific set of needs, you are best served by a team you already know and, if that isn’t possible, a team that is invested in your objectives now and into the future. You don’t want a team that is in the business of “deliver and run”. Teams that are not invested in the operation of your software (whether they are contractors or your own employees) won’t be invested in the security, architecture, and maintenance capabilities of what they deliver. Ideally your software team can’t be logically separated (even if they are physically) from the users and decision makers of the software.

Something else also begins to take form when you invest in persistent teams: they begin to trust that their relationships and partnerships within the team are dependable, and that the longevity of the team isn’t illusory. Persistent teams can form alliances and develop an identity that strengthens the bond between its team members—a luxury that mix-and-match team members don’t have and that their managers wouldn’t want them to develop. If the team is only going to be dissolved at the end of the project, you don’t spend time building the kind of deep relationships that provide a sense of security, self-worth and loyalty to the organization as a whole. These feelings in turn allow teams and team members to deepen their individual and collective skills, to put their heart and soul into their work, and thus build trust with the business team by consistently providing consistent value. In short, when the business invests in persistent teams, the teams invest in the business.

When the business invests in persistent teams, the teams invest in the business.
Click To Tweet

It Ain’t Easy Being a Craftsman

Inherent in all of this is the assumption that business people understand and buy into the value of high-quality software products that stand the test of time and that are easier to maintain. If you have that, you’re golden. If you don’t, then we need to have a discussion of a different nature. Assuming you have the right buy-in, you’ll have to gain the respect and buy-in of your development teams. Traditional developers have either been seduced to believe that they can do no wrong or, paradoxically, no right. For those who believe themselves infallible, they have come to see software development as an art and themselves as artists, and to think that anyone who disagrees simply doesn’t understand because they aren’t developers themselves. On the other end of the spectrum are those who feel they are nothing more than a cog in a great machine, replaceable on a whim, and that the software they are creating is nothing more than a statement of individual power for their “bosses” who are on a power trip. As a result, these developers don’t invest any effort into their craft because the whole process is demeaning.

As a fellow developer, I can say that most developers often don’t know what they’re doing (or why), taking shortcuts just to meet an arbitrary schedule, or worse intentionally skipping steps and skimping on quality. Forced to operate with tools not of their choosing, they come to rely on faulty logic and shortcuts to create code that barely sticks together. Forced to produce a result in insufficient time, they skip steps, including taking the time to understand the problem they are attempting to solve. In some cases, they may be providing the least amount of effort, simply to get out of something they didn’t really want to do in the first place.

Being a software craftsman means assuming a personal code of ethics in spite of it all — a code of ethics where defects are a choice, quality isn’t something you can add on later, and life-long learning and continuous improvement of one’s craft is the only way to ensure that you are always doing the best. The Association for Computing Machinery (ACM) has gone so far as to create their own code of ethics. The craftsman never says, “It works on my machine” or “Bugs are QA’s problem.” Another colleague, Jerry Rajamoney, wrote more about software craftsmanship and its history in this blog.

Being a software craftsman means assuming a personal code of ethics.
Click To Tweet

No team of software craftsmen and craftswomen, no matter how awesome, can do it alone though. I recommend that you form a tight relationship with an individual or organization that will provide a craftsmanship perspective, if you don’t have one already. This “coach” can help you identify, build and maintain teams, but more importantly to grow and maintain those teams over time. Coaches look at the way teams behave, and as a result their perspective will help you find, build, coordinate, cooperate, and maintain teams best designed for your circumstances, improving their craft together to your mutual benefit.

I’ll end with a battle cry, or at least a call to action, from one developer to another. It’s taken right from Dave’s presentation:

  • Be courageous.
  • Stand up to fear-mongers.
  • Use the values that you already possess to create practices that will lead to high-quality software.
  • Get feedback, refine and repeat.

Remember that the time to exercise courage is when you’re developing. Any time after that is too late.

The time to exercise courage is when you’re developing. Be courageous, devs.
Click To Tweet

 

The post Software Craftsmanship as an Act of Courage appeared first on SolutionsIQ.

Categories: Companies

Case Study: ATDD Helps Solve Development Issues

NetObjectives - Tue, 07/19/2016 - 14:26
I’ve been teaching Acceptance Test-Driven Development (ATDD) for many years.   At the start of every course, I ask the attendees for issues they have with their development processes.    After they have experienced the ATDD process, including creation of acceptance tests, I review their issues to see whether they feel that ATDD will help, hurt, or be neutral in respect to those issues.    Here’s...

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

How Rally Does… Strategy Deployment

AvailAgility - Karl Scotland - Tue, 07/19/2016 - 12:30

This is another post originally published on the Rally Blog which I am reposting here to keep an archived copy. It was part of the same series as the one on annual and quarterly planning, in which we described various aspects of the way the business was run. Again, apart from minor edits to help it make sense as a stand alone piece I have left the content as it was.

Strategy Deployment is sometimes known as Hoshin Kanri, and like many Lean concepts, it originated from Toyota. Hoshin Kanri is a Japanese term whose literal translation can be paraphrased as “compass control.” A more metaphorical interpretation, provided by Pascal Dennis in Getting the Right Things Done, is that of a “ship in a storm going in the right direction.”

Compass

Strategy Deployment is about getting everyone involved in the focus, communication, and execution of a shared goal. I described in previous posts how we collaboratively came up with strategies and an initial plan in the form of an X-matrix. The tool that we use for the deployment is the Strategic A3.

Strategic A3s

A3 refers to the size of the paper (approximately 11 x 17 inches) used by a number of different formats to articulate and communicate something in a simple, readable way on a single sheet of paper. Each rock or departmental team uses a Strategic A3 to describe its plan. This forms the basis for their problem-solving approach by capturing all the key hypotheses and results, which helps identify the opportunities for improvement.

The different sections of the A3 tell a story about the different stages of the PDSA cycle (Plan, Do, Study, Adjust.) I prefer this latter formulation from Dr. W. Edwards Deming to the original PDCA(Plan, Do, Check, Act) of Walter A. Shewhart, because “Study” places more emphasis on learning and gaining knowledge. Similarly, “Adjust” implies feedback and iteration more strongly than does “Act.”

This annual Strategic A3 goes hand-in-hand with a macro, longer-term (three- to five-year) planning A3, and numerous micro, problem-solving A3s.

Anatomy of a Strategic A3

This is what the default template that we use looks like. While it is often good to work on A3s using pencil and paper, for wider sharing across the organisation we’ve found that using a Google document works well too.

StrategicA3

Each A3 has a clear topic, and is read in a specific order: down the left-hand side, and then down the right hand side. This flow aligns with the ORID approach (Objective, Reflective, Interpretive, Decisional) which helps avoid jumping to early conclusions.

The first section looks at prior performance, gaps, and targets, which give objective data on the current state. Targets are a hypothesis about what we would like to achieve, and performance shows the actual results. Over time, the gap between the two gives an indication of what areas need investigation and problem-solving. The next section gives the reactions to, and reflections on, the objective data. This is where emotions and gut feelings are captured. Then comes interpretation of the data and feelings to give some rationale with which to make a plan.

The three left-hand sections help us look back into the past, before we make any decisions about what we should do in the future. Having completed that we have much better information with which to complete the action plan, adding high-level focus and outcomes for each quarter. The immediate quarter will generally have a higher level of detail and confidence, with each subsequent quarter afterward becoming less granular. Finally, the immediate next steps are captured and any risks and dependencies are noted so that they can be shared and managed.

Co-creating a Strategic A3

As you can probably imagine from reading the previous posts, the process of completing a Strategic A3 can be a highly collaborative, structured, and facilitated process. One team with which I work closely recently had grown to a point where we would benefit from our own Strategic A3, rather than being a part of a larger, international Strategic A3. To create it we all got together for a day in our Amsterdam office. We felt that this would allow us to align more strongly with the corporate strategy and communicate more clearly what we were doing, and where we needed help.

We began by breaking into small groups of three to four people, mostly aligned around a regional territory. These groups spent some time filling in their own copy of the A3 template. We then reconvened together and each group gave a readout of its discussions, presenting the top three items from each section, which we captured with post-it notes on flip charts. Having gone around each group I then asked everyone to silently theme the post-its in each section until everyone seemed happy with the results. This led to a discussion about each theme and identifying titles for them. We still had quite a few themes, so we finished off by ranking them with dot-voting so that we could be clear on which  items were most important.

Our last step was to identify the top three items on the A3 that we wanted to highlight to the wider business. This turned out to be a relatively simple conversation. The collaborative nature of the process meant that everyone had a clear and shared understanding of what was important and where we needed focus.

A3Karl0 a3Karl1

Corporate Steering

Strategy deployment is not a one-off, top-down exercise. Instead, the Strategic A3 is used as a simple tool that involves everyone in the process. Teams prepare and plan their work, in line with the corporate goals, and each quarter they revisit and revise their A3s as a means of communicating status and progress. As performance numbers become available an A3 will be updated with any changes highlighted, and the updated A3 then becomes a key input into Quarterly Steering.

Categories: Blogs

Free Retrospective Tools for Distributed Scrum Teams

Scrum Expert - Tue, 07/19/2016 - 09:00
Even if Agile approaches favor collocated teams, distributed Scrum teams are more common that what we might think. Many Agile software development teams are based on a virtual organization. This article presents some free online tools that can be used to facilitate retrospectives for distributed Scrum teams. You will find in this article only tools that are supposed to be used for free in the long term. We do not list tools that offer only a free trial based on duration or the number of retrospectives. We will also only mention the tools that have features specifically dedicated to Scrum retrospectives. There are many other tools that Scrum teams might use, from video conferencing platforms to online whiteboard software. Mentioning all these tools will result more in a book than an article. If you want to add a tool that fits these requirements to this article, just let us now using the contact form. Updates July 19 2016: added Fun Retro IdeaBoardz IdeaBoardz is a free online team collaboration tool. It allows teams to collectively gather inputs, reflect and retrospect. It is especially useful for distributed teams. For Scrum retrospectives, you can create two types of boards: standard or starfish. More board options are available (pros & cons, to-dos) that could be also useful. You can edit the titles of the sections of your board. The interface seems very intuitive, but sometimes I ended up in some situations where I didn’t know how to exit gracefully, for instance when I [...]
Categories: Communities

HtmlTags 4.1 Released for ASP.NET 4 and ASP.NET Core

Jimmy Bogard - Mon, 07/18/2016 - 20:20

One of the libraries that I use on most projects (but probably don’t talk about it much) is now updated for the latest ASP.NET Core MVC. In order to do so, I broke out the classic ASP.NET and ASP.NET Core pieces into separate NuGet packages:

Since ASP.NET Core supports DI from the start, it’s quite a bit easier to integrate HtmlTags into your ASP.NET Core application. To enable HtmlTags, you can call AddHtmlTags in the method used to configure services in your startup (typically where you’d have the AddMvc method):

services.AddHtmlTags(reg =>
{
    reg.Labels.IfPropertyIs<bool>()
       .ModifyWith(er => er.CurrentTag.Text(er.CurrentTag.Text() + "?"));
});

The AddHtmlTags method takes a configuration callback, a params array of HtmlConventionRegistry objects, or an entire HtmlConventionLibrary. The one with the configuration callback includes some sensible defaults, meaning you can pretty much immediately use it in your views.

The HtmlTags.AspNetCore package includes extensions directly for IHtmlHelper, so you can use it in your Razor views quite easily:

@Html.Label(m => m.FirstName)
@Html.Input(m => m.FirstName)
@Html.Tag(m => m.FirstName, "Validator")

@Html.Display(m => m.Title)

Since I’m hooked in to the DI pipeline, you can make tag builders that pull in a DbContext and populate a list of radio buttons or drop down items from a table (for example). And since it’s all object-based, your tag conventions are easily testable, unlike the tag helpers which are solely string based.

Enjoy!

Categories: Blogs

Extended Call for Speakers for the Gatineau Ottawa Agile Tour 2016

Agile Ottawa - Mon, 07/18/2016 - 20:10
We have received some amazing speaker submissions for GOAT 2016, thank you to all who took the time to submit their proposals. Summer is finally here, and what a hot one it is! We realize that although you want to submit … Continue reading →
Categories: Communities

Why If You’re Asking “Should I Use Scrum or Kanban?” You’re Asking the Wrong Question

NetObjectives - Mon, 07/18/2016 - 18:46
Note: This blog is co-written by Al Shalloway and Jim Sutton. Abstract: This blog suggests that instead of looking at whether we should choose between Scrum and Kanban, we can see Scrum and Kanban as process patterns and benefit from the best of both.  This is the third in a series of blogs on how Why Understanding Lean Is Essential in an Agile Transformation.  Scrum and Kanban are often...

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

One of Australia’s big four banks takes on ‘Mission Impossible’ with a SAFe Quickstart

Agile Product Owner - Mon, 07/18/2016 - 17:28

Everyone hearing the same message from the same trainers at the same time was a huge enabler for alignment and a ‘one-team’ culture.”
Em Campbell-Pretty, Context Matters

case-study-box-westpac2This latest case study comes to us  from one of Australia’s big four banks, adding to  a growing trend of financial and banking organizations turning to SAFe.

When Westpac needed to add features to its online banking platform in a tight window, a SAFe Quickstart was the answer.

To achieve an ART launch in one week, they began by training everyone at the same time. Midweek, they aligned all teams to common objectives, secured commitment and continued training during planning. By week’s end, they provided orientation for specialty roles, open spaces and tool training for teams.

Next, they brought together 32 leaders across business and IT for two days of Leading SAFe training to discuss SAFe in the Westpac context, generating team excitement. Together, leaders came up with a theme for the train—Galaxy.

SAFe Scrum XP training brought together 60 people in one release train of eight teams over two days with two trainers in one room. The product manager also joined team-level training for both days, leading team members to note his commitment to SAFe.

In response to Westpac’s SAFe approach, team and business engagement went up while cycle time and defects went down.

SAFe at Westpac continues to evolve, with the company holding its third PI Planning event recently.

Read the full case study here for takeaways from Westpac’s dive into SAFe. The study also includes a download of Em Campbell-Pretty’s presentation to AgileAustralia16 with robust speaker notes and some pithy observations.

Many thanks to Westpac and Em Campbell-Pretty of Context Matters for sharing their story.

Stay SAFe,
—Dean

Categories: Blogs

How Rally Does… Annual and Quarterly Planning

AvailAgility - Karl Scotland - Mon, 07/18/2016 - 16:34

This post was originally published on the Rally Blog and I am reposting here to keep an archived copy. It was part of a series in which we described various aspects of the way the business was run. Apart from one minor edit to help it make sense as a stand alone piece I have left the content as it was. However, I suspect that since Rally is now part of CA Technologies, much of what I described has changed.

Rally has a regular, quarterly cadence with which we manage corporate planning, and in which we invest heavy preparation so that we get maximum value. For this year’s Annual Planning, preparation included creating market and opportunity maps and a set of potential strategies, as well as crafting an agenda to help facilitate the collaborative co-creation of the outcomes.

What is Annual Planning?

At Rally, Annual Planning is a two-day meeting involving around 80 people – roughly 70 Rally employees and 10 invited customer representatives. The employees are a mix of people representing all areas of the business: directors and above always attend these key corporate cadences, and other members of the company take turns participating. The customers chosen to join us are those who have shown a keen interest in seeing how we facilitate these large events, and from whom we can learn and get great feedback. Apart from the confidential opening introduction, the customers are involved throughout: spread out across business groups and breakouts, sitting amongst employees, and actively working and contributing as much as anyone else.

This year, we ran Annual Planning a quarter in advance of the financial year we’re about to start. We’ve learned that the initial plan will need validation and refinement, and thus we need to allow time for that to happen. Therefore, the purpose of the two days was to draft our corporate plan for the next financial year, so that we can validate it in the final quarter of the current financial year.

What Do We Do in Annual Planning?

Over the years, we have settled on terminology for corporate planning, inspired by a couple of books. First, Pascal Dennis’ Getting the Right Things Done introduces the terms “True North” and “Mother Strategies.” The True North is the single mantra or slogan that defines where the company wants to be at the end of the year. Mother Strategies are the focus areas that will help us arrive at the True North.

rocks

The True North and Mother Strategies guide the day-to-day departmental work, along with cross-departmental initiatives, which are knows as “Rocks.” Rocks are inspired by techniques described in Verne Harnish’s book, Mastering the Rockefeller Habits. The metaphor of a Rock is based on the idea that if you have a bucket, you should fill it first with a few big rocks: these are the big things you want to accomplish. If there is more space you can then put in pebbles, or medium-sized projects. With any remaining space you can put in sand, or the tactical tasks. Finally, you can add water — the ad-hoc things that arise. If you fail to put the big rocks in first, you will inevitably fill your bucket with just sand and water.

For Rally, the annual plan, therefore, consists of a True North, a number of Mother Strategies, and a set of Rocks. In addition, this year we introduced a new tool to help create transparency and align all the elements: the X-matrix, as described in Thomas L. Jackson’s Hoshin Kanri for the Lean Enterprise. This brought with it a further level of discipline by including the business results we’re targeting, and the measurable improvements we will use to track progress.

Xmatrixblank

As you can see from the blank template above, completing the X-matrix involves deciding on strategic goals, tactical rocks (and other departmental initiatives), measurable improvements, and business results. These are entered into the large white sections alongside each section. In addition, filling in the shaded corner cells of the X-matrix indicates the correlation or contribution between each of these elements, as well as how accountable each department will be for the tactical work. The strength of the correlation or accountability is indicated with one of three symbols according to the legend: strong correlation or team leader, important correlation or team member, and weak correlation or rotating team member. An empty cell indicates no correlation or no team member.

How Does It Work?

The agenda for the two days of Annual Planning involved exploring and defining all these pieces of the puzzle, ultimately filling in a giant X-matrix created on a wall. The picture below shows this partially completed. Taking the advice from the book, we adapted rather than adopted the technique, changing some of the terminology to better fit our context.

Xmatrixblur

Here’s what each day looked like.

Day one was focused on divergence: generating a range of ideas which could go into the initial draft of the plan. We began with a retrospective on the current year; working individually, in pairs, and then in departments, we reflected on what we’d learned that would guide our work in closing out this year and setting us up for next year. Then, the executive team gave a readout of their perspectives and introduced the proposed potential strategies for next year. This led into an Open Space with breakout sessions focused on exploration of rocks and improvements that could implement those strategies. As a result, by the end of the first day we had a good understanding of the current situation, with a variety of potential work that might be needed to meet our goals.

Day two was focused on convergence: refining all the ideas and getting consensus on a plan that could be validated. Groups initially formed around the proposed strategies to look at the plan through a “strategic lens.” Each group discussed how various rocks and improvements aligned to their strategy, and agreed on a proposal that they wanted to make for inclusion in the plan.

annualplanninggroup

In a high-energy session, the proposals were pitched to three of the executives, who accepted them (with a chime) or rejected them (with a horn). Rejected proposals were updated and re-pitched, until we ended up with the X-matrix containing the top 10 rocks and associated improvement measures, along with the strength of the correlation between all the rocks and strategies. Groups then re-formed around departments to look at the plan through a “departmental lens.” They discussed and filled in the X-matrix with the their department’s level of work alignment to the rocks.

At this point we had the majority of the X-matrix complete for the coming year. This was just a first cut, however, so another Open Space session followed to allow discussion of opportunities and concerns, and what needs to be done in the final quarter of the year to validate our assumptions — resulting in a clear set of actions which were shared with everyone.

By the end of the two days we had a clear and single page visualisation of the potential work for the year, why we were doing it, and how we would measure progress, along with a good understanding of the necessary next steps.

What Happens Next?

As an addition to our corporate planning cadence, the X-matrix was a roaring success. It both helped us be disciplined about thinking about measures and results, and gave us great visibility into how all our work is aligned. It still needs refinement, however, and the executive team will look at the final X-matrix and use it to filter and focus on which strategies and rocks can give us the best leverage in meeting our goals. We typically hold ourselves to no more than four mother strategies and we also strive to limit the number of rocks in process.

From the final plan, we’ll craft a True North statement and will begin executing. The regular cadence of quarterly steering meetings will revisit the X-matrix as a focal point to help us inspect and adapt. We’ll check business results and improvement measures and form rocks, which will start and end according to the necessity of the work and the need to make it transparent across this well-defined review cadence.

Categories: Blogs

Agile2016, July 25-29, Atlanta, USA

Scrum Expert - Mon, 07/18/2016 - 16:31
Organized by the Agile Alliance, Agile2016 is the annual Agile conference and the biggest event in the world on Agile software development and Scrum project management. Agile2016 offers an unprecedented opportunity to learn from world-class experts and thought leaders while networking and collaborating with up to 2,500 Agile professionals from over 40 countries. In the agenda of the Agile2016 conference, you can find topics like “Dynamic Reteaming”, “Distributed Agile: Evolution or Delusion?”, “Coaching Nightmares: Insights we can Learn from Gordon Ramsay”, “Finding Agreement When Everyone Is Right”, “Making Infrastructure as Awesome as Agile Software”, “The Executives Step-by-Step Guide to Leading Large-Scale Agile Transformation”, “Creating Alignment with The Product Wall Release Planning Workshop”, “Intro to Agile Product Management”, “Decoding the Enigma of Product Discovery & Feature Prioritization”, “How to Get Your Whole Team Talking”, “Visual Communication for Groups”, “The Agile Database Techniques Stack: Bridging the Agile/Data Cultural Divide”, “Building Large, Mission-Critical Software and Systems with SAFe 4.0”, “Organizational Agility: It’s Not a Sprint, It’s a Marathon”, “Just Enough: Minimally Viable Agile”, “Agile Testing Maturity – What does “Good” Look Like?”. Web site: http://www.agilealliance.org/agile2016/ Location for the Agile2016 conference: Atlanta, GA, USA
Categories: Communities

How To Find Work (Freelance or Otherwise)

Derick Bailey - new ThoughtStream - Mon, 07/18/2016 - 13:50

A YouTube viewer asked a question, wondering what I would do if I were starting over today and needed to find work (among other things).

NewImage

It’s a good question – and one that is important for everyone to consider, even if you’re not currently looking.

Before answering the question, though, the viewer asked me to talk about how I got started with freelance work.

It’s a long episode, but it’s full of good advice and some fun back-story.

Categories: Blogs

How do you terminate a project in your org?

lizkeogh.com - Elizabeth Keogh - Mon, 07/18/2016 - 10:46

We all know that when we do something new, for the first time, we make discoveries; and all software projects (and in fact change efforts of any variety) target something new.

(You can find out what that is by asking, “What will we be able to do when this is done that we can’t do right now? What will our customers, our staff or our systems be able to do?” This is the differentiating capability. There may be more than one, especially if the organization is used to delivering large buckets of work.)

Often, though, the  discoveries that are made will slow things down, or make them impossible. Too many contexts to consider. Third parties that don’t want to co-operate, let alone collaborate. A scarcity of skills. Whatever we discover, sometimes it becomes apparent that the effort is never going to pay back for itself.

Of course, if you’ve invested a lot of money or time into the effort, it’s tempting to keep throwing more after it: the sunk-cost fallacy. So here are three questions that orgs which are resilient and resistant to that temptation are able to answer:

  1. How can you tell if it’s failing?
  2. What’s the process for terminating or redirecting failing efforts?
  3. What happens to people who do that?

If you can’t answer those questions proudly for your org, or your project, you’re probably over-investing… which, on a regular basis, means throwing good money after bad, and wasting the time and effort of good people.

Wouldn’t you like to spend that on something else instead?

 

 


Categories: Blogs

A Personal Blog About Working Hard

NetObjectives - Sun, 07/17/2016 - 10:31
I read Seth Godin's Blog everyday. This morning's A Drop In the Bucket made me stop and think (actually most do, this one more than others).  I don't think Seth would mind my including it here. A drop in the bucket, By Seth Godin When you buy a glass of wine at a nice restaurant, it doesn't come in a beer stein. If it did, the 4 ounces would be dwarfed by the glass and you'd feel like your host...

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

Storytelling Product Canvas - Act 1: from Business Model to UX

Agile Thinks and Things - Oana Juncu - Sat, 07/16/2016 - 20:45

Storytelling Product CanvasThe secret of humans success is their capacity to create fictions and largely cooperate around those. No other species are able to align themselves around non real things such as "values", "laws", or "Business".  Our brain capacity to organise effectively around imaginary things developed in us an unique capability that became the main driver of human history : storytelling.
Business development is not appart of it. A successful business is a good story about entrepreneur's mission, her client aspirations, and the unfolded offering of products and services.
A Canvas or A Story ?
In entrepreneurship and business areas, defining a Canvas is THE THING. I do like canvases it's a good tool to describe a container, and containers are every change-maker's tool. For example, I love Ash Mayura's Lean Canvas. I wrote a bunch of articles on Lean Canvas one of the the most effective business awareness enabler's in the Lean Startup landscape. Canvases is reassuring for our linear cause-to-effect thinking. And it's not enough to trigger stuff from our fuzzy-creative thinking enjoy like inspiration, innovation and enthusiasm. Our brain is story-wired. What makes us move forward are stories. Therefore, here is the challenge: transform a canvas into a story. A mix of storytelling techniques mapped on the Lean Canvas, I decided to call the "Storytelling Product Canvas".

Step 1: Envisioning: What is the (product) story about?
When a novelist writes a story, the first think is to decide what kind of story she wants to write:
"Boy meets girl?"
"Girl meets success?"
... and so on.
 When an entrepreneur wants to build a business, ultimately she believes her idea will make the world better, at least for someone. If you think this is a too idealistic way to see the world and believe entrepreneurs have ideas only to have money and be successful, I invite you to test the market by launching an idea with the outstanding outcome to make you rich and successful.
While waiting for the market study mentioned before, let's name the first section of the Storytelling product Canvas, "Envisioning".  The question to answer here by an entrepreneur starting her business is "Why will my product create a better world?"

Step 2: Customers: Who's story is this ( product story)?When decided as an entrepreneur what is your vision about your business building a better world, the very next question is: "Who's world?"
Just like  heroes of a story, your product is aimed to create a compelling story about its users. This story is sometimes called User Experience.
Just like a writer who makes tons of studies to shape a good character entrepreneurs should observe their users and customers to be. An entrepreneur organises "customer safaris" to observe their life and their environment, to note their behavior without judgment.
Modesty - the key of a balanced businessA big challenge of an entrepreneur is to push her judgments over customers behaviour. In our easy path of blaming others, biasing what customers should want, is an easy trap to fall into. For this reason, one of the main skills an entrepreneur should develop is Active Observation along with Active Listening : Listen to understand and let surprising ideas emerge, rather than observing to confirm our former ideas. Confirmation Bias is one of the main daemons of Entrepreneurship.
Customers' Status QuoIn a good story,  a novelist  sets the stage: describes what is the environment of the characters, what is appealing and or constraining in that environment so that characters stick to it. The same apply to entrepreneurship. A "customer Safari" is an enabler to discover their "status quo". As an entrepreneur, you can find out how your users to be deal in their current daily context with the activities your business is aimed to improve.
Status Quo has always an emotional load. Find out what is that load: is it painful, soaring, joyful...
Making a better world through an eventually innovative business will necessarily have an emotional impact on characters , euh... users and customers , of course. Start early by observing those!

Temporary ;) Conclusion
The former paragraphs describe the initial 2 steps of starting a new business with a "product storytelling" perspective:
Envisioning: What is your vision of a better world?
Customers : Who are they? What is their actual context ( Status Quo)?

Dear reader, if this post raised some curiosity and interest,  let me know and.I'll develop the other sections of my "product storytelling canvas" in future posts.
Until then here are other related posts:

Why Agile Development Hooks US
Customer Development is a Kind of Customer Coaching
Listening To Awareness
Product Storytelling
Manage Like A Pirate
Storymapping is the plot of your product story







Categories: Blogs

Knowledge Sharing


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