Skip to content

Feed aggregator

Why I Am Not A Change Agent

The New-New Mr. Smith, The Change AgentHow do you present the job that you do ? Write it down.
Good.
Now see if words/expressions  like "help", "become", "improve", "how to", "implement"  "change", "need to", are part of your description.
If some of these are present in your description, take a moment and make two groups. Put those words that you used as applying to others,  in the 1st group. Then put those that refer to yourself in a 2nd group . How many items are in the 2nd group in respect with those in the 1st one ? What these numbers tell you ? Well, I'll tell what they have told me. Help ( euh, and coaching ... ) Cannot Be Pushed On People If you're called  to provide a given expertise when working with people and organisations, it might be tempting to "force in" your expertise. If you're successful , those people you're working with,  will acquire the necessary knowledge to operate in the field of your expertise. Faster this will be true, more efficient you'll be. Simple as that, this is the end of the story, unless it's not.  If would have been a dead end . Mandated expertise and "help" are some of those privileged impossible things that find themselves a cosy corner in the sweet spot of wishful thinking.
If I say ( e.g.) "I help organisation improve their team work" , it actually reflects my wish to be such a great professional who can help improve team work.
Help is the qualification of my work from my perspective. The same service I provide might be experienced by those that receive it (the helped people, you know ...) as little value overwork, meaningless noise ...
Real help  can be qualified as such by people that received it.
That's why I know I'm no professional helper for  any individual or organisation. I host containers that people fill in with their context and the change they want to see.
Well, if I'm not helping,  let's see what may chances are to be a change enabler ...

Culture : From Values To Biases And BackNo change will happen until the culture will let it. OK, so focus on culture ! I do believe culture gives a group an identity . I do believe individuals influence culture .  I do believe culture gives a sense of belonging .
Either you join a culture because its principles are aligned with your values, either you live by it( like the one you are born in) and learn to prise and nurture its values.
The set of values is the foundation of each culture .  The set of common beliefs is the set of practices that result from prizing those values.Let's say we live in a culture that values "cleanliness" most.  What will be our understanding of a culture that values "spare water" most?  What will be their understanding of ours?  What if instead of genuine observation we start to "rate" the set of values on a scale that has as reference our own values ?  This is at least irrelevant at worst dangerous .

History have had some many, many tragic examples.
No change will happen until the culture addressed by that change will let it.  If changing culture needs a shift in group's values, better start to shift my own ones.  It's the "start with yourself" principle of congruence . This having being said, the task is in no way easier.  If I start with myself, hmmm, let's say I've got this, what will I start with ?
Remember the "cleanliness" and "spare water" cultures mentioned roughly 10 lines above ?
"Liminal Thinking", a pattern defined by Dave Gray offers an alternative to "value the values of other cultures by our own values" . Great Stuff !
First we're invited to start the journey to ourselves by accepting a statement :
"The reality where I'm comfortable in, with my people, my cats, my umbrellas , my Agile principles ;) - is just set of beliefs I've built far from the real reality that, by the way, I don't even have a clue want it is".
From here, we can continue the journey into assumptions that created those believes ,  needs that generated those assumptions, experiences that we recall as relevant to our needs.
Why is this helpful ? Because we might realise why , and realise that other cultures have their own "whys".

I Have No Idea If I Help 
If I'm in my group and my beliefs are my reality and of those I respect and care , why should I care if my reality is different of people that I might not care of and respect so much ?  Because at some point,  either their reality floods our cosy bubble , either I might have that fancy job description ( remember , it is now about  40 lines way up in this post ! ) that says I "help"  other people change , and they might not be so wildly willingly to recognise me as the best next Messiah they can get.
If I stay in my own "Self-Sealing Bubble" I might get angry or frustrated because "they just don't get it".
If I inspect my bubble I can share the story of why I'm in and shake it to take a limp in the liminal space outside of it . Then ask questions and invite to answer,  like Alice in Wonderland does. Alice is never angry , nor frustrated and has no idea if she shakes Wonderland.
Is this ... "help" ? Even farther, is this ... "help to change" ? I have no idea . That's why I'm not a change agent. When I first made the exercice I made up and proposed in the beginning of this post,  now a far 60 lines up to the top,  I fixed myself a goal : get rid of any of those words in the group that applies them to others . And get rid of them in the group that applies to myself , because they might be irrelevant to anyone but me.
 To steal an expression I heard in a open Space chat at ALE2015 with my  Trust Artist friend Olaf Lewitz I'm just "shaking" myself . See if anything happens.

Some Material To Promote Myself ( because it make me feel cool)
I held an workshop at the Agile2015  on Dave Grey's model combined with the archetype of "Third culture kids"  to trigger awareness of our Agile self-sealing bubble :) .
The support is here

Related posts and other cool stuff Agility Adoption Rather Than Agile At Scale
The answer to "Why" Is Ahead A Geography of Time , R. LevineThird Culture Kids, David C. Pollock
Categories: Blogs

An Aggressive But Realistic Delivery Date?

Leading Agile - Fri, 08/28/2015 - 15:06

I recently received an email asking about release planning. The sender wanted help understanding how to move ideas through the flow to create a mature backlog. The note went on to ask how to properly “estimate, prioritize and reach an aggressive but realistic delivery date”.

My immediate thought was, this is agile: total project story points divided by team velocity yields the duration of the project. And delivery date then only depends on when you start and how well you manage risks and dependencies. If you want an “aggressive” or what I’ve come to understand as “overcommitted” plan you should just crack out your Gantt charts and stop pretending that you’re agile.

Before I dashed off a sharp email, I chatted with an associate and came to a different understanding of “aggressive planning”. He made the point that teams may not be aware of unused capacity. And establishing an accurate team velocity is a “trust but verify” process. Trust the current velocity, but periodically verify its accuracy. After a team establishes a sustainable and consistent delivery velocity, you should run an experiment. Increase the number of story points planned for a sprint by some number. If the team successfully delivers the sprint, then that total number of points is used for planning successive sprints. If the team sustains that pace, then reset the team’s velocity to the new number.  Run the experiment again.

This cycle of experiments continues until the team can’t keep up. At that point you have verified the team’s velocity as the last consistently maintained pace.  This final velocity is likely a bigger number (more aggressive) than the starting velocity number and so now a project’s duration will be shorter than calculated with the untested velocity. But the new velocity is verified; consider the date realistic.

The post An Aggressive But Realistic Delivery Date? appeared first on LeadingAgile.

Categories: Blogs

Publications on the Business Benefits of Agile

Ben Linders - Thu, 08/27/2015 - 23:13
I have collected research, studies and reports that provide insight into the business benefits of agile in a new agile and lean tool: Business Benefits of Agile. Continue reading →
Categories: Blogs

Lean, Agile & Scrum Conference, Zurich, Switzerland, September 2 2015

Scrum Expert - Thu, 08/27/2015 - 10:00
The Zurich Lean, Agile & Scrum Conference (LAS) is a one day conference that focuses on Lean and Agile approaches for software development. The conference provides both German and English content. The keynotes of the of the Zurich Lean, Agile & Scrum Conference will be Ralf Westphal and Niklaus Brantschen. In the agenda you can find topics like “Agree or Disagree, but Commit”, “Facilitation Dojo”, “Process- and Team-Performance”, “Transforming your Culture with Working Agreements”, “Storytelling in a Technical World”. Web site: http://www.lean-agile-scrum.ch/ Location for the Zurich Lean, Agile & Scrum Conference: TECHNOPARK ...
Categories: Communities

Swisscom: Disrupting the TV Industry with Agile

Rally Agile Blog - Wed, 08/26/2015 - 16:00

Chances are, you or someone you know has “cut the cord” recently — canceled your cable TV subscription service in favor of the alternatives, like a set-top box, rabbit ears, streaming services such as Netflix and Hulu, or Internet-delivered media. Here in the United States, one survey found that more than eight percent of cable TV subscribers had cut the cord last year.

One thing you may not have considered is how this cord-cutting, multiplied by the thousands, is radically disrupting the cable and communications industry.

Swisscom, Switzerland’s leading telcomm company, was mindful of fast-changing industry trends when it decided to insource the development work for a new IPTV (Internet-delivered television) initiative. The company wanted to get its Swisscom TV 2.0 service out to the marketplace quickly, before its competitors; however, its organizational structure and culture were not set up for agile delivery.

Laying the Groundwork

Bringing the development work for the IPTV initiative in-house was just one of many steps the company took to transform itself: it also built strong, cross-functional trust and transparency by co-locating developers with business owners, DevOps, and vendors across near-shore teams in six countries. Much of this groundwork already was laid when the company discovered agile a few years ago.

“We simply did what made sense for us, and we figured it out as we went along. Only later did we realize that our efforts overlapped with existing practices for agile at scale.”

- Simon Berg, Agile Program Manager, IPTV Engineering

Scaling Up

With support from Swisscom’s head of TV development and technology, the IPTV group adopted and scaled agile approaches: it implemented the Scaled Agile Framework® (SAFe®) and took advantage of Rally Unlimited Edition’s performance in tracking work at the portfolio level.

“We chose the Rally platform for its portfolio-level management capabilities. No other solution could link strategy to execution across 12 teams, with rolled up visibility of multiple programs.”

- Simon Berg

Launch Time

Swisscom launched TV 2.0 in 2014, and in just over a year racked up more than half a million subscribers — that’s more than 15% of all Swiss households. Meanwhile, Swiss cable companies have lost 98,000 TV customers in the past 12 months.

Swisscom’s agile transformation played a key role in the initiative’s success. The company cut development cycles from 12 months down to 3-6 months, and the teams’ use of agile testing and validation approaches improved quality and minimized rework. Perhaps most importantly, Swisscom didn’t just deliver on-time: it delivered the right product for the market. Being agile allowed the company to respond to shifts in direction and keep up with fast-changing consumer demands.

“Ultimately, the culture and the people are how we innovate and win in an industry that is constantly being disrupted by new technologies.”

- Simon Berg

Read the entire Swisscom case study, then learn more about big room planning and Rally’s agile at scale platform.

Rally
Categories: Companies

The Product Roadmap is Not the Project Portfolio

Johanna Rothman - Wed, 08/26/2015 - 15:38

I keep seeing talks and arguments about how the portfolio team should manage the epics for a program. That conflates the issue of project portfolio management and product management.

Teamsandvalue

Several potential teams affect each project (or program).

Starting at the right side of this image, the project portfolio team decides which projects to do and when for the organization.

The product owner value team decides which features/feature sets to do when for a given product. That team may well split feature sets into releases, which provides the project portfolio team opportunities to change the project the cross-functional team works on.

The product development team (the agile/lean cross-functional team) decides how to design, implement, and test the current backlog of work.

When the portfolio team gets in the middle of the product roadmap planning, the product manager does not have the flexibility to manage the product backlog or the capabilities of the product over time.

When the product owner value team gets in the middle (or doesn’t plan enough releases), they prevent the project portfolio team from being able to change their minds over time.

When the product development team doesn’t release working product often, they prevent the product owner team from managing the product value. In addition, the product development team prevents the project portfolio team from implementing the organizational strategy when they don’t release often.

All of these teams have dependencies on each other.

The project portfolio team optimizes the organization’s output.

The product owner value team optimizes the product’s output.

The product development team determines how to optimize for features moving across the board. When the features are complete, the product owner team can replan for this product and the project portfolio team can replan for the organization. Everyone wins.

That’s why the product owner team is not the project portfolio team. (In small organizations, it’s possible people have multiple roles. If so, which hat are they wearing to make this decision?

The product roadmap is not the project portfolio. Yes, you may well use the same ranking approaches. The product roadmap optimizes for this product. The project portfolio team optimizes for the overall organization. They fulfill different needs. Please do not confuse the two decisions.

Categories: Blogs

Roadmapping with Enterprise Agile – Balancing Capacity Against Demand

Leading Agile - Wed, 08/26/2015 - 14:46

Frequently I’m asked:

There is a seemingly endless set of good ideas that are demanding capacity in our organization, how do we make our demand and capacity visible so that we can create a roadmap that will best balance demand against capacity?

This is the key question that most organizations are struggling to answer while trying to create an actionable roadmap.  I have a couple of basic rules that I use to help keep the answer simple.

  1. Identify a common unit of measure for quantifying demand and capacity, and
  2.  Identify a unit of time that best represents the period of time that will be used for planning

Rule 1: Identify a common unit of measure for quantifying demand and capacity

As you may recall, my favorite unit of measure is always currency.  That said, I find that when roadmapping it’s frequently helpful to use a more abstract measure that will similarly represent both capacity and demand.  Currency provides too many variations as an answer to the question “How much of this do you want to invest or how much capacity will you spend to bring idea x to fruition?”  To address this, I typically recommend that an organization either use a program team or a delivery team as the unit of measure.

With the common unit of measure set to either program or delivery teams, we can now answer the following question to help with balancing demand and capacity:

We have 20 delivery teams worth of capacity available, how many of them are we either willing to dedicate towards bringing this idea to market or how many do you think you will need to bring the idea to market?

Rule 2: Identify a unit of time that best represents the period of time that will be used for planning

This is a great start; but, we haven’t yet applied time to the process.  To really map demand against capacity we will also need to be able to answer the question of how long are we willing to apply the team to this idea.  If a planning team needs to release items into the market within months then I tend to encourage them to plan against team weeks.  If their release plans are more oriented around quarters, half-year or year durations I will usually steer them to think in terms of team quarters.  With both the unit of measure and unit of time selected we can now map both capacity and demand for a period of time.  As an example, I may answer the above question as follows:

I am willing to allocate 5 delivery teams for a quarter to bringing this idea into the market.  That will leave 15 teams worth of capacity open for other ideas or features that I want to create as well this quarter.

Using team weeks or quarters as a unit of measure and planning duration for your roadmap enables a planning team to simplify the capacity that is available by planning period down to a ratio of planned capacity/available capacity. (Eg.  5/20 or 25% of the available capacity for the quarter, with the above example).

Finally, when the time is right, it is possible to translate the cost of a roadmap item by establishing an average cost per team (say $250,000 per quarter) and then multiplying that cost by the number of teams allocated for the period.

What are your thoughts? Have you used anything similar or different?

Thanks!

The post Roadmapping with Enterprise Agile – Balancing Capacity Against Demand appeared first on LeadingAgile.

Categories: Blogs

Agile Alliance Elects 2016 Board of Directors

Scrum Expert - Tue, 08/25/2015 - 21:34
Agile Alliance has announced that its membership has overwhelmingly approved the slate of candidates put forth for the 2016 Board of Directors. Results for the 2016 election were reported to the Agile Alliance membership by Board Secretary Shane Hastie at the annual membership meeting on August 5 during Agile2015, the organization’s annual North American conference held at the Gaylord National Hotel in National Harbor, Maryland. The Agile Alliance membership elected three members to the Board of Directors for three-year terms: Dr. Rebecca Parsons (USA), Paul Hammond (England), and Victor Hugo Germano ...
Categories: Communities

An Iterative Waterfall Isn’t Agile

I’ve noticed something disturbing over the past two years. And it’s occurred uniformly with teams I’ve worked with all across the world. It’s the tendency to create an iterative waterfall process and then to call it agile.

An iterative waterfall looks something like this: In one sprint, someone (perhaps a business analyst working with a product owner) figures out what is to be built. 

Because they’re trying to be agile, they do this with user stories. But rather than treating the user stories as short placeholders for future conversations, each user story becomes a mini-specification document, perhaps three to five pages long. And I’ve seen them longer than that. 

These mini-specs/user stories document nearly everything conceivable about a given user story.

Because this takes a full sprint to figure out and document, a second sprint is devoted to designing the user interface for the user story. Sometimes, the team tries to be a little more agile (in their minds) by starting the design work just a little before the mini-spec for a user story is fully written. 

Many on the team will consider this dangerous because the spec isn’t fully figured out yet. But, what the heck, they’ll reason, this is where the agility comes in.

Programmers are then handed a pair of documents. One shows exactly what the user story should look like when implemented, and the other provides all details about the story’s behavior. 

No programming can start until these two artifacts are ready. In some companies, it’s the programmers who force this way of working. They take an attitude of saying they will build whatever is asked for, but you better tell them exactly what is needed at the start of the sprint.

Some organizations then stretch things out even further by having the testers work an iteration behind the programmers. This seems to happen because a team’s user stories get larger when each user story needs to include a mini-spec and a full UI design before it can be coded.

Fortunately, most teams realize that programmers and testers need to work together in the same iteration, but not extend that to being a whole team working together. This leads to the process shown in this figure.

This figure shows a first iteration devoted to analysis. A second iteration (possibly slightly overlapping with the first) is devoted to user experience design. And then a third iteration is devoted to coding and testing.
This is not agile. It might be your organization’s first step toward becoming agile. But it’s not agile.

What we see in this figure is an iterative waterfall.

In traditional, full waterfall development, a team does all of the analysis for the entire project first. Then they do all the design for the entire project. Then they do all the coding for the entire project. Then they do all the testing for the entire project.

In the iterative waterfall of the figure above, the team is doing the same thing but they are treating each story as a miniature project. They do all the analysis for one story, then all the design for one story, then all the coding and testing for one story. This is an iterative waterfall process, not an agile process.

Ideally, in an agile process, all types of work would finish at exactly the same time. The team would finish analyzing the problem at exactly the same time they finished designing the solution to the problem, which would also be the same time they finished coding and testing that solution. All four of those disciplines (and any others I’m not using in this example) would all finish at exactly the same time.

It’s a little naïve to assume a team can always perfectly achieve that. (It can be achieved some times.) But it can remain the goal a team can work towards.

A team should always work to overlap work as much as possible. And upfront thinking (analysis, design and other types of work) should be done as late as possible and in as little detail as possible while still allowing the work to be completed within the iteration.

If you are treating your user stories as miniature specification documents, stop. Start instead thinking about each as a promise to have a conversation. 

Feel free to add notes to some stories about things you want to make sure you bring up during that conversation. But adding these notes should be an optional step, not a mandatory step in a sequential process. 

Leaving them optional avoids turning the process into an iterative waterfall process and keeps your process agile.

Categories: Blogs

Scrum & Kanban with MantisBT

Scrum Expert - Tue, 08/25/2015 - 16:59
MantisBT is a popular open source bug tracker. Its architecture features a plugin system that allows extending its functionalities. This article lists the MantisBT plugins that allows to integrate an Agile project management approach like Scrum or Kanban around the basic features of MantisBT. There are currently four open source plugins that allows to add Scrum and Kanban features so that you can integrate an Agile project management approach with the basic functionalities of the MantisBT open source bug tracking tool. AgileMantis agileMantis tries to bridge the gap between the open source bug ...
Categories: Communities

As a Product Owner, How Can I Use Axosoft?

About SCRUM - Hamid Shojaee Axosoft - Tue, 08/25/2015 - 16:41

Your product should always be your priority. Your company’s product requires a vision, and many agile teams look to the Product Owner to set that vision. Whether you use the term Product Owner or another term such as Product Manager, we’re here to share how you might use Axosoft in that role. Let’s start with a few key outcomes Product Owners strive to accomplish:

  • Maximize the number of features that can be completed within a release.
  • Decrease the time it takes to turn feedback into prioritized backlog items.
  • Decrease the time it takes for feature requests to be understood by the development team.
  • Increase the Return On Investment of work (e.g. features).

The outcomes listed above depend heavily on how the Product Owner decides to manage their product backlog, which is where Axosoft can help! As in our previous Use Case articles, we’re going to assume you are familiar with the Axosoft basics. If not, start with this video series or go through the opening tutorial again.

How do I manage my backlog?

Project folders are the best place for your backlog in Axosoft. Every item lives in a project folder inside the Organize Panel, regardless of item type, and its tree structure gives you the flexibility to nest your data in a way that fits your organization style. If you want to keep things simple, you can keep everything in one project folder, but we’re going to show you something more advanced.

What is a backlog example in Axosoft?

Consider managing your product backlog over multiple project folders. Here’s an idea of one potential tree structure:

In this example, we are nesting the icebox and the release backlog under the Product Backlog folder.In this example, we are nesting the icebox and the release backlog under the Product Backlog folder.

Feature requests come in from customers, from the team internally, and from everywhere in between. These requests land in the general “Icebox” project folder for review by the Product Owner. He or she (or insert your preferred gender pronoun) has them color-coded by workflow step:

  • New
    • New feature request from the team, customers, etc.
  • Rejected
    • Request is closed and rejected.
  • Approved-Icebox
    • This means that this is a good feature and will be considered for future releases.
    • This item stays in the Icebox for now.
  • Approved
    • This request will be moved into the upcoming release backlog.
    • Special workflow setting enabled.
Here we have grouped by workflow step (and color) for the Icebox project folder Here we have grouped by workflow step (and color) for the Icebox project folder

In this example, we did something special with the Approved workflow step. We configured a step action to detect when an item has been placed into the “Approved” workflow step, and automatically move that item over to the Release Backlog project folder.

Editing the Approved workflow step, I can change the assigned project of any item that gets approved. Editing the Approved workflow step, I can change the assigned project of any item that gets approved.

This helps to triage and collect the most valuable requests into one backlog for the next level in refining. We’ll come back to this Release Backlog folder shortly.

How can I populate my backlog with requests from my team?

If you are making ample use of the help desk functionality in Axosoft, then you are likely getting a good share of feature requests from your ticket volume. Similarly to how you can escalate issues as defects, you can do the same for feature requests. I recommend watching this video for all the details (and just substitute the word “bug” with “feature request”).

Otherwise, you have a few more options. First, you can open up your customer portal and provide a tab for feature requests. Your customers might get overenthusiastic though so proceed with care on this front.

Here's how we have our portal if you need a sample.Here’s an example of our Customer Portal.

Next, you can import items from a CSV spreadsheet into your backlog. This may come in handy if you need to perform a bulk import of existing feature requests.

Lastly, you can manually create each request like you would any item. This is a fantastic catch-all.

How do I groom my backlog in Axosoft?

Let’s go back to our Backlog project folder example. Managing the product backlog is an ongoing activity and typically requires the following from the Product Owner:

  • Order the backlog by business value
  • Remove or demote items that have lost business value
  • Add or promote items that have business value
  • Split items
  • Merge items
  • Associate/relate items (as a way of indicating business value)

In our example, we just promoted some of our Icebox items into the Release Backlog. We also rejected a few requests outright, while placing others on hold for the future. This takes care of the second and third bullets, and rank mode will take care of the first. In list view, Rank Mode is enabled by toggling this down arrow in the main toolbar.

This is where you rankThis is where you rank.

Once enabled, we can drag and drop each backlog item and order them based off our business value criteria. Don’t worry if you have pages of items to go through here in Axosoft; rank mode will persist across pages. Consider, however, throwing in a filter or removing items altogether to preserve the utility of your backlog. Access the context menu (right-click) to add to top, or unrank quickly.

Pleasant shortcuts courtesy of right-clicking.Pleasant shortcuts courtesy of right-clicking.

Once you leave rank mode, go back to list view and “Sort by Rank” to see where your backlog stands.

If you don't have access to rank mode, you can at least sort by rank.If you don’t have access to rank mode, you can at least sort by rank.

If you want to merge or split items then consider making use of subitems.  To merge duplicate items, you can nest them under one parent item by creating a new parent item and then just dragging and dropping the duplicate requests on top of it. If you’re feeling fancy, you can also use related items to handle duplicates and prioritize only the primary item.

Subitems are helpful for splitting items too. I have also seen folks duplicate an existing item and simply adjust the information to reflect the “split.” This would be great if one item turns out to be two or three requests in one.

How can my team access my groomed backlog for release planning?

Everything we have done so far in our example will culminate with the Axosoft Release Planner. First, let’s select the Release Planner tab in Axosoft:

Here it be.Here it be.

Next we want to make sure our example Release Backlog folder is selected in the Organize Panel.

Click your backlog folderClick your backlog folder

Next, let’s sort by rank–and now you are ready to plan your release. From here, you build out your upcoming release. Yes!

If you want to see the release planner in action, check out this video, my other video, or this blog post. For now, consider making this a part of your release planning meeting. Show the team where everything stands in the backlog, and begin to answer the two major release planning questions:

  • What will get done in this release?
  • How will it get done?

As you begin assigning items to your team members, you will gain insight into how much work each team member has on their respective plates, and how much more work each team member can fit into this release.

Alternatives

You are not required to jump straight to the release planner for your release planning meeting. We have seen teams create an additional project folder that represents the official backlog for their sprint or release. So in addition to the grooming made to the Backlog folder, a Product Owner might move items to a Sprint – “August 2015 backlog” while running the release planning meeting. This allows the team to draw from the Backlog folder for subsequent releases as well.

Final thoughts

Alright, so let’s review those top outcomes from earlier:

  • Maximize the number of features that can be completed within a release.
  • Decrease the time it takes to turn feedback into prioritized backlog items.
  • Decrease the time it takes for feature requests to be understood by the development team.
  • Increase the Return On Investment of work (e.g. features).

Axosoft is but one tool that you can maximize to get the outcomes listed above. Product Owners will also need to strive for constant communication between all levels of their organization. It’s a challenge, and we hope the above saves you time and sweat!

You might also like:

As a Support Rep, How Can I Use Axosoft?

As a Developer, How Can I Use Axosoft?

Categories: Companies

Increasing Software Quality with Visual Management

Ben Linders - Tue, 08/25/2015 - 12:18
One of the principles from agile and lean software development is transparency. Making things visible helps teams to decide what to do and to collaborate effectively with their stakeholders. It can also help to increase the quality of software. This post provides ideas how you can do that. Continue reading →
Categories: Blogs

Kickstarter Idea: Mac OS X Package Manager

Developing on the Mac has generally been an awesome experience over the years especially with OS X and the UNIX underpinnings. The long pain point in this area is the lack of a solid supported package manager. It’s not in Apple’s DNA to worry about power users who actually use the terminal, and they’re unlikely to ever consider it important enough to delegate resources too. MacPorts and its hipster cousin Homebrew have been around for a while, but they’re always a bit rough around the edges, missing packages here and there, old versions, and sometimes they need extra tinkering just to install. In all it’s a most un-Mac like experience.

I don’t know that it will ever happen, but I know I’d support a Kickstarter that promised to maintain a Mac package manager like rpm or apt for OS X. I don’t care if they use Homebrew or Macports and just make it more robust, or build a new one from scratch. I’d just like a simple install of all those open source libraries. Yehuda Katz did a simple installer for Ruby and Rails on OS X a few years back via a Kickstarter, so I know there’s precedent and this would impact a lot more developers. Saving hassle is certainly worth some bucks for a kickstarter.

Categories: Blogs

Using Commercial Scrum Tools for Free

Scrum Expert - Mon, 08/24/2015 - 15:40
If the development of open source Scrum tools was in vogue some years ago, a lot of these projects have now been abandoned. Some are still active like IceScrum, but this is because their development is sponsored by a commercial hosted option There is however an alternative to manage your Agile project if you have a low budget… and a small team. Some providers of commercial Scrum tools provide a free version of their software. Only Scrum tools that offer a long term free commercial product are mentioned in this article, ...
Categories: Communities

SwanseaCo, Swansea, Wales, September, 7–8 2015

Scrum Expert - Mon, 08/24/2015 - 15:19
SwanseaCo is a conference that takes place in Wales that discusses Agile development and Software Craftsmanship. The conference includes keynotes and presentations, a discussion panel and time between sessions to network and connect with fellow Agile software developers from around the world. In the agenda of the SwanseaCo conference you can find topics like “What Is Continuous Inspection, Anyway?”, “Level Up Your Tests”, “Managing Global Teams: Lessons Learned”, “Surrender the Illusion of Control”, “Spreadsheets are Code”, “Software Craftsmen Need to Stop Coding so Much”, “Lean UX and Agile Development Taking the ...
Categories: Communities

My Agile 2015 Roundup

Johanna Rothman - Mon, 08/24/2015 - 15:06

Agile 2015 was the week of Aug 3-7 this year. It was a great week. Here are the links to my interviews and talks.

Interview with Dave Prior. We spoke about agile programs, continuous planning, and how you might use certifications. I made a little joke about measurement.

Interview with Paul DuPuy of SolutionsIQ. We also spoke about agile programs. Paul had some interesting questions, one of which I was not prepared for. That’s okay. I answered it anyway.

The slides from Scaling Agile Projects to Programs: Networks of Autonomy, Collaboration and Exploration. At some point, the Agile Alliance will post the video of this on their site.

The slides from my workshop Agile Hiring: It’s a Team Sport. Because it was a workshop, there are built-in activities. You can try these where you work.

My pecha kucha (it was part of the lightning talks) of Living an Agile Life.

I hope you enjoy these. I had a great time at the conference.

 

Categories: Blogs

The Importance of Leadership and Management In Agile

NetObjectives - Mon, 08/24/2015 - 14:54
Leadership and management have often been given short shrift in the Agile world.  Management isn’t mentioned once in the Agile Manifesto and the Scrum community characterized management as uncommitted for years (fortunately the chickens and pigs story has been mostly abandoned).  At Net Objectives we believe that both leadership and management are not only important, but essential.  It is part of...

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

No More Sucky Demos

Leading Agile - Mon, 08/24/2015 - 14:15

Ever seen a sucky demo? One that doesn’t start on time, with technology issues, too many people in the room, people on the phone not on mute, confusion over what stories will be demo’d and who will demo them? Let’s have no more sucky demos. Here are some thoughts on how to make that happen.

Plan It!

Decide which stories need to be demo’d well in advance of the demo. Some teams decide this before or during sprint planning. Go a little further and specify the demo script in advance, sort of the Acceptance Criteria for the completed demo. Just add that to the story description. Make it part of story grooming and the story readiness criteria (i.e. a story can’t be taken into a sprint without demo requirements specified). During planning, put a sub-task on the story for doing the demo and assign it to someone at some point during the sprint. At the very latest, decide and publish the demo plan at least 24 hours in advance. The Product Owner (PO) should have a say in that decision.

“Ok, we’ll get started in a few minutes… just waiting for a few more people to join.”

Start on time. Give no quarter. Find out how to turn off the announcement chimes (entry and exit chimes) and on-hold beeps in WebEx and GoToMeeting.

  • In GoToMeeting on Mac, in the Audio pane, there is a drop-down button to turn this off. I’m told there are 3 dots in the Audio pane on Windows. Click that. It used to be an Edit button and may still be if you have an older version of GoToMeeting or GoToWebinar?
  • I’ve read about how to do this in WebEx, but haven’t tried it. Check the audio settings.
“Ok, we need a few more minutes, we’re still getting set up here.”

Practice. Those doing the demo need to get exceptionally good with the tooling (Screen share, audio conference, video conference, projector/monitor, starting on time, muting, volume, changing presenter, etc.). Don’t wait for improvements to come with time. Be intentional. Have each person who will ever be involved in a demo watch the training video for presenters that are provided from gotomeeting or webex or whatever. Find such a video and have everyone watch it.

Have a GoToMeeting/WebEx kata. A Kata an exercise of scripted activities to do. Like a coding kata, have kata for everyone to practice using GoToMeeting/WebEx. They could do the practice with an intern, or together in pairs, especially in onshore/offshore pairs. It should cover give and accept presenter mode, share screen, share screen 2, stop sharing, share individual app, turn on mic, turn off mic, muting other people, turn volume up and down, set someone else as presenter, turn off entry/exit chimes, turn off on-hold beeps, etc.

“Oh, uh, I don’t know why it did that. Wasn’t expecting that.”

Rehearse. Do a dry run. Don’t surprise the PO. Your PO should see working software before the demo.

Faster Feedback

Another alternative is to have the tester/developer call for a live demo during the sprint as stories are finished. Just call the PO over and show ’em what you’ve got running.

This might not work if you have a large team or a large number of people on the PO Team or a large number of PO’s and BA’s that need to see the demo. To deal with that, maybe allocate daily demo time, kind of like PO office hours. Or only require that story’s one BA (instead of all the BAs and POs) see the demo.

Asynchronous Demos

Record it. As an alternative to a long demo with everyone in the room on the last day of the sprint, consider having the developer and tester who did the story record their demo as they finish the story, then send out the link to the recording. This will get feedback from PO’s and BA’s earlier in the sprint. This will allow Product Support and new hires to watch demos later when it is more relevant to them. It will also allow people to only watch the demos they care about.

Recording will also allow the team to do it over if it doesn’t go well the 1st time they attempt to record it.

People can still ask questions, just offline. The only downside is that everyone can’t hear the questions that others ask, but you could post the recordings on yammer or confluence or somewhere so that Q&A can be done online.

“…so now I’m going to show you… Hi. Who just joined?”

Sometimes there are too many people in the demo. Too many voices, too many side conversations. Some people don’t seem interested. Some people join the conference call late.

Consider excluding non-essential people. Make the focus of the demo to suit the needs of the BA and PO only. Disregard the secondary purpose of the demo, which often is for other people to know about recent changes. Another option to consider would be to record the demos or to have separate demos for the secondary purpose (to narrow the audience and improve focus).

Rock the House

A great end of sprint demo will turn people on to agile and increase support for your team. Do them well, or don’t do them at all.

The post No More Sucky Demos appeared first on LeadingAgile.

Categories: Blogs

Polish edition of Valuable Agile Retrospectives book released

Ben Linders - Sun, 08/23/2015 - 21:18
The book Wartościowe Retrospekcje Agile has been released on Leanpub. This is the 8th translated edition of the successful book Getting Value out of Agile Retrospectives. Continue reading →
Categories: Blogs

Coaching Corner: Quotes for Coaches

NetObjectives - Fri, 08/21/2015 - 23:42
I find that coaches often need inspiration themselves to inspire others.  I like quotes because they remind me of what I know deep inside of me but have perhaps forgotten in the face of a challenging situation. Here are some of my favorites: by Winston Churchill Success consists of going from failure to failure without loss of enthusiasm. Never, never, never, never, never, never, never give...

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

Scrum Knowledge Sharing

SpiraPlan is a agile project management system designed specifically for methodologies such as scrum, XP and Kanban.