Skip to content

Feed aggregator

Pair Programming with Eclipse

TV Agile - Tue, 05/23/2017 - 17:17
At Eclipse, new actors are challenging the classic Eclipse IDE: * Che: the next-gen Eclipse cloud, putting the developer workspace and the IDE on your browser * Orion: an extensible browser IDE * Flux: a new message-based architecture for cloud-based developer tooling These technologies open lots of new kinds of features such as real-time live […]
Categories: Blogs

Product Owner Assessment

Scrum Expert - Tue, 05/23/2017 - 16:26
The product owner role is responsible that the production of the Scrum team meets the requirements of the customers and deliver value for the organization. This is an important role that requires...

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

Info Radiation vs Info Refrigeration - a metaphor

Agile Complexification Inverter - Tue, 05/23/2017 - 03:48
Is a metaphor a form of lightweight model?

"All models are wrong, some models are useful."
-- George Box

The metaphor of information radiation is quite well know to many in the software industry.  Did you ask why?  Maybe because much of our work is very hidden from view, until we run the program and the computer interprets the code to produce some desired outcome.  Even that outcome may be obscured from view, and we must produce reports upon the data that the program produced.  So in a world where smoke and mirrors are common, one antidote to the common problem of not knowing where one is along the path toward product completion, a visualization is a powerful tool.

Generally speaking the information radiator has similar properties to the old fashion building heat radiator that used a steam media source to heat heavy iron and radiate the heat from the iron into the room.  It feels great to be standing next to a radiator when you've just come in from the cold.

What is the refrigeration process - what's required to cool some air?  Currently we use the 200 year old Carnot cycle to produce the cooling effect that your summers are known for.  I doubt that my home of Dallas Texas would be the Mecca of IT if not for Mr. Nicolas Carnot and his research into what would become air-conditions environments.  A comfortable 70 degrees indoors while the Texas sun is 95 in the shade.

Pressure-Volume diagram of Carnot cycleI will leave the internal working of the AC unit to your study (I did it back in college - fascinating stuff).

When we put information is some systems we encode or compress it in such a way that the storage is efficient.  Think of a data base, significant work is done upon the data to store it.

When we pull it out of those systems we also must now do work to make the data into information, and then do more work to make the information understandable by the people that have little knowledge of where the data came from, the purpose of storing the data and the context from which that data/info may have resulted.  Someone will interpret that context, information and purpose and try to convey all this in a summary of the meaning behind larger data sets that the important people reviewing the information have time for.  This expansion of the information and subsequent summarization or generalization takes energy from the system as a whole.

pondering the connections - AC to info refrigeration metaphor....  what do you see in this metaphor?

is there a useful model to play with?

Categories: Blogs

Defining “Scaling” Agile, Part 1: Creating Cross-Functional Feature Teams

Johanna Rothman - Mon, 05/22/2017 - 18:34

I keep encountering confusion about what scaling agile is. I’m writing what I think is a 4-part series to define it so we all talk about the same thing.

When I ask people to define what they mean by scaling agile, they talk about these possibilities:

  1. They have agile developers. They want agile testers. This is creating cross-functional agile teams for projects.
  2. They have had successful one- or two-team agile projects. Now, they’re ready for an agile program.
  3. They have agile product development (it might be called IT or Engineering or R&D or something else), and they want to share agile approaches across Marketing, Finance, HR.
  4. They want to build an entirely agile business.

Each of these is different. Each solves a different problem for the organization. This post is about #1: the developers have been agile in their single function team. They want to bring the testers along and create cross-functional teams. (It could be the other way around where the testers are agile, but I haven’t seen that. I have seen testers using iterative and incremental approaches, but often that’s a reaction to the developers.)

I wrote about the problem of staggered iterations in How Long Are Your Iterations, Part 1. When the developers are on a different cadence than the testers, they don’t act like a cross-functional feature team. The “team” isn’t delivering a finished feature. They’re not solving problems like a team. They often have a ton of WIP (Work in Progress). Using iterations does not make a team agile.

On the other hand, if this is where you can start, do start there. The next part in your “scaling” of agile is to move to cross-functional feature teams. That’s where the team works together, in a collaborative fashion, to create finished features. You might do this in iterations, especially if you’ve only heard of Scrum. You might use a kanban board to see all the flow of work through your team and your bottlenecks.

I keep talking about “your team.” Agile approaches use cross-functional teams who focus on delivering features. I’m not big on component teams. That’s because they postpone delivery of finished features. I also hate the idea (and name) of “shared services.” I’ll blog about that later.

You might think, “The developers are agile. We’ll scale agile to the testers.” If that’s the way people think about agile in your organization, maybe that’s the best you can do. Here’s a possible reframe for you:

Scale agile from one function to a cross-functional team.

When you (and your managers) start to think about cross-functional teams rather than functions, you start to realize the benefits of agile.

If you think scaling agile is sharing agile between functional teams, consider reading my upcoming book, Create Your Successful Agile Project. I’m still in editing and then it goes out for review. We expect it will be available in July.

I do have reviewers, but if you are struggling with your agile approach, let me know if you would like to be a reviewer. We might have room for another couple of reviewers.

Categories: Blogs


I was flying home from a client visit last week at the airport getting ready to board the plane when the gate agent announced that the flight was gonna be delayed by ten minutes due to some unspecified mechanical issue. Ten minutes later they announcement another ten minute delay. They did this two more times.

So what was going on? Did the airlines not want to admit upfront that they had a 40 minute delay so they fed the delays to us ten minutes at a time? Or did the person who is doing the work really not understand how long it was going to take? I started thinking about how common it is for people to not be able to provide good estimates. Sometimes they underestimate the complexity, or maybe student syndrome sets in, or they're just overly optimistic.

It was ironic, but part of the work with my client that week was explaining the technique of relative estimates using t-shirt sizes and story points. The team I was working with was  new to agile and used to the old way of doing absolute estimates, which as we all know are not as accurate because of things like student syndrome or Parkinson's Law.

So how do we get better at estimating? I think the real question should be how we recognize estimates for what they are. An uncertain prediction of a future event. Even when we use story points, we won't know our true velocity until after a couple iterations when the team has time to come together. At the beginning of the project, we need to recognize how much uncertainty we have. So instead of saying "that will take about 2 months" we should say "that may take 2 months, but it could take as long as 3 months." So we provide not only the estimate but some measure of the uncertainty that goes with it. Similarly, if we think a story might be 13 points, but there's a lot of uncertainty, we should state that and make the story 20 points (or 21 if you're being strict with your Fibonacci sequence). Now if only I could get the airlines to provide a more accurate estimate the next time there's a delay...or at least how certain they are!
Categories: Blogs

The Simple Leader: Document the Current State

Evolving Excellence - Mon, 05/22/2017 - 10:26

This is an excerpt from The Simple Leader: Personal and Professional Leadership at the Nexus of Lean and Zen

All truths are easy to understand once they are discovered;
the point is to discover them.
– Galileo Galilei

Before you can improve something, you must first have a very clear understanding of what its current state is. Don’t assume you know what it is. Go to the gemba, be it the factory floor, the shipping and receiving area, your office, or even take a minute to focus on yourself, and observe what is going on. It is important that you get close to the action. The worst thing you can do is try to document the current state from a meeting in a faraway conference room.

To document key processes, such as accounts payable, production, sales, and so forth, document the current step-by-step activities of each of those processes. How long does each step take? How are they physically laid out? Where do backlogs occur?

If you are documenting the current state of a company or organization, there are a variety of ways to do it. You can use the key metrics of the organization, including financials, customer service, quality, operations, and so forth. If they are not the appropriate metrics, create new ones. Then decide how your observations compare to your expectations, industry average, etc. What are your suppliers saying about you? Your customers? Your employees? What about your competition?

Once you have your observations, you might want to consider using some standard analysis methods as well. These include a SWOT (strength, weakness, opportunity, threat) analysis, Porter’s Five Forces (to analyze your industry), a PEST analysis (for the external macroenvironment), and BCG or GE methods to look at product lines.

From a Lean perspective, you may also want to look at how some key Lean tools are being used (5S, kaizen, poka-yoke, etc.). But remember, they are just tools. Moving forward, you need to determine if they are the right tools for the problem you are trying to solve. What is the problem or opportunity you want to address?

When documenting the current state, be sure to include other people with potentially other perspectives to validate the results. This will help you counteract your own biases. The current state becomes the baseline from which you will start improving. Finally, as I mentioned earlier, consider documenting the current state of you. What are you currently dealing with, your hopes, fears, and aspirations?

Categories: Blogs

Refactoring to Microservices – Using a Document as State

Xebia Blog - Fri, 05/19/2017 - 15:12

In a previous installment of our Microservice refactoring effort, I’ve introduced a ShopManager and a Clerk to implement the shopping process (see this blog). I ended up with a JSON document transferred between services. To make life easy for myself I just parsed all of the document using Spring magic. This time I will discuss […]

The post Refactoring to Microservices – Using a Document as State appeared first on Xebia Blog.

Categories: Companies

LAST Conference, Melbourne, Australia, June 29-30 2017

Scrum Expert - Fri, 05/19/2017 - 12:00
The LAST conference is a one-day conference about Lean, Agile, Systems Thinking that takes place in Melbourne, Australia. It is a event for practitioners that encourages participation and interaction...

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

Regional Scrum Gathering Rio, Rio de Janeiro, Brasil, July 6-8 2017

Scrum Expert - Fri, 05/19/2017 - 11:00
The Regional Scrum Gathering in Rio de Janeiro is the largest Scrum event in Latin America. In the past, this Agile conferences taking place in Brazil received about 500 people and discussed topics...

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

The Simple Leader: Share Generously

Evolving Excellence - Fri, 05/19/2017 - 10:24

This is an excerpt from The Simple Leader: Personal and Professional Leadership at the Nexus of Lean and Zen

Teaching is a gift you give not only to others, but also to yourself.
You give and you receive, you teach and you learn.
– Andrea Goeglein

When I became president of the medical device company, I already had a decade of Lean experience. I knew what fundamentals needed to be put in place, what systems needed improvement, and what knowledge needed to be transferred.

Instead of ordering this or that program to be implemented, I decided to help the team identify problems and point them to potential solutions. For example, when we were taking too much time to find production supplies, I suggested they consider using a Lean concept known as 5S. Instead of teaching them everything myself, I let the team take charge of implementing it. The team embraced this management style: first they learned about 5S, and then they implemented what they learned. We repeated this process with several other Lean concepts. They would go and learn about it, and I would coach them on implementation. I shared my knowledge and experience, but a funny thing happened along the way: the team also taught me some new methods they had identified and developed.

In the end, there were still a couple of changes I needed to dictate, one being the morning standup meeting. The team did not think that adding a new daily meeting would be beneficial. But when I made the meeting mandatory, I also let them know exactly why it was being done, why it was important to me, and what results we should expect from it. Within a few weeks they also saw the value, and I know that it continues to this day, more than three years after I left the company.

Another thing we did at the company was to emphasize employee training. People want to learn, and it’s a measure of your respect for them (and their brains) that you provide opportunities for them to learn. I’ve seen far too many organizations that believe it is too expensive to send employees to conferences, work- shops, and other events. Yes, it costs money, but those folks come back motivated and wanting to improve! Isn’t that worth a couple grand? If you cannot recapture the investment of a conference or workshop, you aren’t asking enough of your team.

Every year, I sent quite a few employees to events, choosing people that had demonstrated a passion for learning as well as some that I thought could learn a lot if they were appropriately motivated and respected. In each case, I asked them to come back with three to five ideas that we should implement now, as well as three to five ideas that were pretty cool and we should keep in mind for the future. They presented these ideas to our leadership team as a group, and it was then up to us to evaluate and implement them. The process was difficult, but the new ideas easily paid for the trips, many times over. Properly nurtured, the employees who had gone to the trainings became forceful proponents for improvement.

Sharing your knowledge and experience doesn’t just have to be within your organization. One of my most rewarding activities is writing the blog I started over ten years ago. My posts have ranged across many topics, some far outside of Lean, but the response I’ve received has been tremendous. I’ve also met some incredible people who have become very valuable friends and colleagues—some are now business partners. The effort has also improved my writing ability and helped me organize my thoughts, which eventually even led to this book!

I’ve also learned a lot about recruiting over the years. I’ve had several failures where professionals with great experience and resumes ended up not being the right fit. I have learned that the best predictor of executive success, more than experience, education, references, or personality, is the ability to share and teach new knowledge. More specifically, executives should have a craving for new knowledge, the capability to distill the knowledge, and an ability to effectively share the knowledge. Those types of individuals are few and far between, but they are incredibly valuable and can radically change an organization.

Categories: Blogs

Agile Israel, Tel Aviv, Israel, June 20 2017

Scrum Expert - Fri, 05/19/2017 - 10:00
Agile Israel is a one-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...

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

Cycle Time and Lead Time

Agile Complexification Inverter - Fri, 05/19/2017 - 04:01
Our organization is starting to talk about measuring Cycle Time and Lead Time on our software engineering stories.  It's just an observation, but few people seem to understand these measurement concepts, but everyone is talking about them.  This is a bad omen...  wish I could help illustrate these terms.  Because I doubt the measurements will be very accurate if the community doesn't understand when to start the clock, and just as important - when to stop it.

[For the nature of confusion around this terms compare and contrast these:  Agile Alliance Glossary; Six Sigma;; Lean Glossary.]

The team I'm working with had a toy basket ball goal over their Scrum board...  like many cheep toys the rim broke.  Someone bought a superior mini goal, it's a nice heavy quarter inch plastic board with a spring loaded rim - not a cheep toy.  The team used "Command Strips" to mount it but they didn't hold for long.

The team convinced me there was a correlation between their basketball points on the charts and the teams sprint burndown chart.  Not cause and effect, but correlation; have you ever stopped to think what that really means?  Could it mean that something in the environment beyond your ability to measure is an actual cause to the effect you desire?

I asked the head person at the site for advice, how could we get the goal mounted in our area?  He suggested that we didn't need permission, that the walls of the building were not national treasures - we should just mount it... maybe try some Command Strips.  Yes, great minds...  but what about getting fired after putting holes in the walls scares one from doing the right thing?  How hard is it to explain to the Texas Work Force Commission when they ask why you were fired?

The leader understood that if I asked the building facilities manager that I might get denied - but if he asked for a favor... it would get done.  That very day, Mike had the facilities manager looking at the board and the wall (a 15-20 minute conversation).  Are you starting the clock?  It's Dec 7th, lead time starts when Mike agreed to the team's request.

The team was excited, it looked like their desire was going to be granted.  Productive would flourish again.

Over the next few days I would see various people looking up at the wall and down at the basketball goal on the floor.  There were about 4 of these meetings each very short and not always the same people.  Team members would come up to me afterwards and ask...  "are we still getting the goal?"... "when are they going to bring a drill?"...  "what's taking so long?"

Running the calendar forward a bit... Today the facilities guy showed up with a ladder and drill.  It took about 20 minutes.  Basketball goal mounted (Dec 13th) - which clock did you stop?  All of the clocks stop when the customer (team) has their product (basketball goal) in production (a game commences).

I choose to think of lead time as the time it takes an agreed upon product or service order to be delivered.  In this example that starts when Mike, the dude, agreed to help the team get their goal mounted.

In this situation I want to think of cycle time as the time that people worked to produce the product (mounted goal) - other's might call this process time (see Lean Glossary).  And so I estimated the time that each meeting on the court looking at the unmounted goal took, plus the actual time to mount  the goal (100 minutes).  Technically cycle time is per unit of product - since in the software world we typically measure per story and each story is some what unique - it's not uncommon to drop the per unit aspect of cycle time.

Lead time:  Dec 13th minus Dec 7th = 5 work days
Cycle time:  hash marks //// (4)  one for each meeting at the board to discuss mounting techniques (assume 20 m. each); and about 20 minutes with ladder and drill;  total 100 minutes

Lead Time 5 days; Cycle Time 100 minutes
This lead to a conversation on the court - under the new goal with a few team members about what we could do with these measurements.  How if one's job was to go around and install basketball goals for every team in the building that a cycle time of 100 minutes with a lead time of 5 days might make the customers a bit unhappy.   Yet for a one off, unusual once a year sort of request that ratio of 100 minutes to 5 days was not such a bad response time.  The customer's were very happy in the end, although waiting for 5 days did make them a bit edgy.

But now what would happen if we measured our software development cycle time and lead time - would our (business) customers be happy?  Do we produce a once in a year product? (Well yes - we've yet to do a release.) Do our lead times have similar ratios to cycle time, with very little value add time (process time)?


Well it's January 5th and this example came up in a Scrum Master's Forum meeting.  After telling the tale we still did not agree on when to start and stop the two watches for Lead Time and Cycle Time.  Maybe this is much harder than I thought.  Turns out I'm in the minority of opinions - I'm doing it wrong!

Could you help me figure out why my view point is wrong?  Comment below, please.

LeanKit just published an article on this topic - it's very good but might also misinterpret cycle time.  I see no 'per unit' in their definition of cycle time.  The Lead Time and Cycle Time Debate: When Does the Clock Start? by Tommy Norman.

An Experiment in measuring the team's cycle time:
After a bit of time reflecting, debating, arguing with colleagues and other agilitst online I've decided to publish a little experiment in measuring cycle-time on a scrum team.  Here's the data... what does it say?  How do you think the team should react?  What action should be next?  What should the team's leadership feel/think/do?

The Story:  This team has been working together for a while.  The sprints are numbered from the start of the year... an interesting practice, this team uses 2 week sprints, is practicing Scrum.  Took a nice holiday and required some priming to get back in the swing of things after the first of the year (you see this in the trend of stories completed each sprint).  Cycle Time for a story on trend is longer than the sprint, this correlates with typical story "carry-over" (a story started is not finished in one sprint and is carried over to the next sprint).  Generally a story is finished in the sprint but not in sequence or priority - they all take at least the full sprint to get to done.  There is no correlation of story size to cycle time.

Now those are the facts more or less -- let us see what insights we might create from this cycle time info.  With no correlation of story size to cycle time AND little consistency of number of stories finished in a sprint (trend of # of stories: 1, 6, 7, 2, 2). The question arrises - what is the controlling variable that is not being measured that effects the time it takes to get from start to finish with a story?  Now that the team can see that the simplest things we could track do not have a strong effect on the length of time (or the through-put) a story requires... and that means the process is not under good control - we can start to look around for some of the uncontrolled (invisible factors) -- if we a courageous enough!

We reflected that many of the stories that carry over and are virtually unpredictable in size/time/effort appear to have large delays or multiple delays within their implementation phase.  So we devised a quick and dirty way to track this delay.  The assumption that this delay inherent in the work will perhaps be the unmeasured / uncontrolled variable that throws the correlation of story size with cycle-time out of kilter.

Our devised technique for tracking delay per story - a yellow dot on the task with a tick mark for every day the task is stuck in-process (delayed).

If this article spawns another article which references this one that references that one... does the internet cause a singularity?  I'd ask you to click this link, but you may implode:  Derek Wade - On Time.

See Also:

LeanKit published this excellent explanation of their choices in calculating cycle time within their tool:  Kanban Calculations: How to Calculate Cycle Time by Daniel Vacanti.
LeanKit Lead Time Metrics: Why Weekends Matter
Elon Musk turns a tweet into reality in 6 days by Loic Le Meur
The ROI of Multiple Small Releases

The Hummingbird Effect: How Galileo Invented Timekeeping and Forever Changed Modern Life
by Maria Popova.  How the invisible hand of the clock powered the Industrial Revolution and sparked the Information Age.

Categories: Blogs

Draft Scope and Boundary

Agile Estimator - Thu, 05/18/2017 - 23:14

Size Distribution of New Development Projects

From the very beginning, all participants should start to form some expectation regarding the size of the application to be estimated. At the top of the post is the size distribution of new development projects. The size distribution is expressed in IFPUG function points. The methodology presented here uses IFPUG sizing measures. At this point, there is not enough industry experience to present a similar distribution for SNAP points. Even if there was, function points would still be the best way to express the size of an application that is about to be built. SNAP points become more important when estimating the schedule and effort for projects that have changes in functionality, such as enhancement projects. In any case, The sizing methodology presented here will take into account both function points and SNAP points.

if an applications is 50 function points or less, it should simply be assigned to an agile team and they should handle any estimating and reporting. The initial team size should be based on management’s experience with similar applications. Team size can be adjusted in future iterations.  At the other extreme, only 10% of the projects studied had function point counts that exceeded 2,000. There is simply not enough experience with these larger applications to proceed without extra caution. When an estimator is convinced that a project is more than 2,000 function points in size, the possibility of dividing the project into separate components should be considered. Otherwise, the process can still be used, but additional care must be taken to insure functionality is not being missed. These huge projects can almost never be done by a single agile team.

According to industry practice, establishing scope and boundary is a must for any estimating exercise. Since this process is basically function/SNAP point based, it made sense to use the standard IFPUG definitions for these attributes. Scope and boundary rules are basically the same for both function points and SNAP points. The first step it to draft the scope and boundary of the application to be estimated. The scope and boundary may change during the estimating process. This may be the result of better understanding of the project or a change in scope. When this happens, the estimating process has to be reworked.

Prior to defining the scope and boundary, the purpose and type of assessment must be determined. This process was developed with a certain purpose and type in mind. The purpose of any assessment is to estimate the size of an application to be developed so that the size can be fed into an estimating model. The size will include both functional and non-functional requirements. All agile application development efforts involve taking some software and converting it into some other software with additional or changed capabilities. This type of assessment is an enhancement project. New development can be treated as a special case of enhancement. In new development, there is no existing capability to begin with. In days of old, the waterfall methodologies favored this special case of new development. You began with nothing and continually transformed models until you ended up with a completed application. For example, you did analysis and ended up with a data flow diagram of the entire system to be built. Then you transformed that into a structure chart to show all the components to be built. Then you coded the design to have a system. That was classic new development. In agile development, you are continually transforming working software from one form into another. A simple release is built that contains a workable subset of requirements. Then, the attributes of that release are changed and augmented to produce the next release of the software. It is basically software development by continual enhancement. Fortunately, this approach also works if the team is tasked with enhancing an existing piece of software that they did not build.

According to the IFPUG Counting Practices Manual (CPM), the scope “defines a subset of the software being sized.”  It identifies which functions will be included in the size so as to provide the best estimate. A project might only be enhancing certain portions of a system. There may be reusable components that will supply some of the functionality to be delivered. All of this must be considered in the scope. For people using the IFPUG sizing methodologies, sizing can be complicated. For people using the process outlined here, it is fairly straight forward. The scope includes any existing software attributes that will be changed and any new attributes that will be added. People familiar with IFPUG methodologies may ask about deleted attributes. Most estimating models ignore deleted attributes. They are ignored here.

The CPM states that the boundary “defines what is external to the application.” If the application being built must interact with other applications, then these applications are outside of the boundary of the one being developed. People who use the application are outside the boundary of the application. The bad news is that establishing boundaries can be complicated. For example, is there a boundary around Microsoft Office? Or, is the boundary around Excel, Word , PowerPoint, etc.? How about QuickBooks? It seems like there should be a single boundary around QuickBooks. However, there are several versions of QuickBooks. There are several for the PC that have extended functionality. There is one for the Mac. There is a version that only works on the web. Some of them probably share portions of each other’s code. Where does the boundary get drawn? Fortunately, there are two pieces of good news. The first is that when using this process, the boundary is usually drawn around the attributes of the application that will be changed and includes the things that will be added. Sometimes, there will be changes made to multiple applications. In that case a boundary will be drawn around each. Who decides and how do they do it. This is the second piece of good news. It is the users, and probably the product owner, that is most qualified to make this determination. They make it by deciding how users view the software they are using. For example, do they think they are using Microsoft Office or Microsoft Excel? It is probably the latter and that will drive their boundary decisions.

The scope and boundary may emerge from a study of the initial stories that define an application. Otherwise, they must be established by some other collaboration between the estimator(s) and the stake holder(s) of the application. The definitions of scope and boundary for this process are completely consistent with those found it the IFPUG CPM. Of course, these definitions of scope and boundary are probably generic enough to be used with virtually any sizing measure.

People who are familiar with the SNAP process may be surprised that no mention has been made of partitions. Partitions are identified as part of this process. However, they are not identified at this time.

Categories: Blogs

They are “Lessons to be Learned”, not “Lessons Learned”

Leading Answers - Mike Griffiths - Thu, 05/18/2017 - 18:10
The suggestions, observations and ideas we capture at retrospectives are not Lessons Learned. That would imply we have already learned from them and will not make that mistake again. Instead, they are Lessons-to-be-Learned which is subtly different but stresses the... Mike Griffiths
Categories: Blogs

Adult Cognitive Development and the Agile Mindset

BigVisible Solutions :: An Agile Company - Thu, 05/18/2017 - 17:00

The science of Adult Cognitive Development has been around for quite some time, but William Rowden maps that science to the Agile Mindset and an Agile Transformation. His insights are fascinating and help him identify behaviors that are not aligned with an Agile mindset, and how to help his clients move in the correct development direction. William is speaking not from theory, but from practical application within clients in the US, China and Mexico.


Howard Sublett:  William is a senior Agile consultant at SolutionsIQ with expertise leading enterprise Agile adoptions for clients in the US, China, and Mexico. He is a skilled communicator and collaborator who not only can program in over 20 computer languages, but is fluent in English, Spanish, and is rapidly learning Mandarin.

In this episode, William and I discuss Agile cognitive development and the Agile mindset. In his work with clients, he’s mapping adult cognitive development within an Agile transformation. He shares his understanding of how a client’s professional development model needs to aligned and focused on the transformation. This work’s helped him to recognize behaviors that don’t match the expectation of an Agile mindset, and how to help them move in the developmental direction.

Again, thank you for joining us, and now, on to the conversion.

William, thank you so much for spending some time with me today. This is actually the very first time of carrying my gear, that I actually get to sit down in SIQ headquarters and actually record here, instead of in some pub somewhere or in wherever it is. Thanks for coming back from the client and sitting down with me a little bit.

William Rowden: Sure.

HS: Yup, so, you’ve got a monster topic that you and I have kind of been wrestling around — how to actually frame this into some way that makes sense for maybe a listener, and we kind of came up with this idea that what you’re trying to bring to the table is of the Agile mindset and what we could learn from adult cognitive development.

WR: Right.

HS: So, that is something I know very, very little about. I don’t know about the listeners in here, but that’s a huge topic.

WR: Right.

HS: So, we talk a lot about Agile mindset, but you’re bringing kind of the science of this cognitive development to it. Can you break it down for us just a little bit?

WR: Sure. Exactly. I did Agile development for about 10 years before I got into sort of helping people do Agile development. When we started helping people do Agile development, we developed a sort of intuitive sense about how is it that you help people change. It’s an important quality for a coach to support people through change.

But about three years ago, I started looking for a more formal explanation for the things that we know intuitively about an Agile transformation. We know when we go into a client and we present Agile to them, that we’re not just asking them to learn a new set of facts or a new way of doing things. We’re asking them to learn a new mindset, and we even put up slides saying, “A new mindset is needed.” But what really does that mean if we’re talking about helping people transform their mindset? I went looking for science that would help us understand what that really looks like and how we can help that happen.

HS: That’s huge because I know that most of us kind of look and go, “Yeah, he’s got it, and he doesn’t.” Or we can kind of see it and they get it and it’s something by the behavior that we see, but sometimes it’s not. It’s how they approach different problems and stuff.

WR: Right. Right.

HS: So you are bringing to the table several steps here, and we’ve got this wonderful thing that you’ve got on the wall we’re trying to look at, and we’ll try to put a picture of it in the cliff notes of what we’re doing of all these development stages. Can you kind of walk us through where people start at in cognitive development and where they go to?

WR: Sure. First, I want to comment a little bit about what you said about people get it or they don’t, and this is actually the differentiator between different stages of cognitive development. It’s how you make meaning. It’s how you make sense of your world. It’s how you interpret what’s happening to you. The people we see that “get it” are ones that are in a stage where they’re making meaning in a way that’s compatible with what we’re teaching with Agile, and if they’re not, then maybe there’s a little bit of growth that’s needed. This is based on adult developmental psychology that’s just an extension of childhood developmental psychology.

The famous childhood developmental psychologist is Piaget. If you go out on YouTube and you Google “Piaget experiments,” there’s an entertaining set of videos of children at various ages being asked to solve simple problems. You can see in childhood a breakpoint where they start to be able to see the world in a different way and answer questions and solve different kinds of problems. Until recently, it was thought that that just sort of ended, like when you became physiologically an adult, that that sort of development was done.

One of the famous adult developmental psychologists used to go to conferences, and his brain science colleagues at Harvard would make fun of him, so like, “Whatever it is you think you discovered in adult development, we know that the brain doesn’t change. It’s wired by the time you become an adult.” But in the last couple of decades, we’ve discovered that’s not true. Your brain continues to change in its structure over the course of your life. The childhood development stages actually continue into adulthood and so they have a lot to tell us about helping people transform the way they think.


HS: So, there’s probably two personas here that you’re probably talking to about this. From a coach’s perspective, they’re trying to identify those stages in the clients that they’re working with, and then from the individuals, the leaders, managers within organizations— they probably want to self-identify with the stages in which you’re talking about, right?

WR: Absolutely. If you’re a coach, you want to support people who change. If you’re a manager, you want to continue your own professional development because Agile leadership requires a little more than some of more traditional leadership of you personally and professionally.

Also, if you’re an Agile manager, you want to support your people as they go through the development that’s necessary to adopt an Agile way of working in an Agile mindset.

HS: You’ve got some stages for us here, and I will let you walk us through a little bit of it.

WR: Sure. So from a developmental perspective, there’s about three stages of childhood which is not really that important — just to understand that adulthood is a continuation, and then adulthood at this time, three stages identified as well, and so they would be stage … You’d start the childhood at zero and so we’re talking about stage three, four, and five for an adult.

Most adults spend most of their life climbing from three to four. You’re developing different ways of thinking and more complex ways of looking at the world. The development psychologist that I rely on most for adult psychology is Robert Kegan, and he calls these three stages, the three, four, and five, he calls them the socialized mind, the self-authoring mind, and the self-transforming mind. The self-transforming mind is typically a very small percentage of the population, so we’re really talking about the socialized mind and the self-authoring mind.

Now the interesting thing that caught my attention as an Agile coach is if you look at the expectations that we have of people going through an Agile transformation, a significant number of the expectations are self-authoring mind expectations. In order to do them well, you need to actually progress developmentally in some cases in order to achieve what you want to achieve.

So I have some examples of each of those on the chart if you want to talk about it.

HS: I was going to say, is there a way to describe the stage of a socialized mind, the stage three? What does that kind of look like?

WR: Sure. So, your socialized mind person, this is the team player. This is the person who maybe doesn’t seek out leadership, but is good in terms of a follower, does that well, seeks direction for their work because that’s really where they are.

If you read Stephen R. Covey’s “7 Habits of Highly Effective People” when that came out decades ago, he talked about “dependent, independent, interdependent.” This is the dependent stage. This is where you’re saying, “Tell me what to do.” Not always that extreme, but we actually run into developers that are basically “I would prefer that you give me a detailed specification of what I’m supposed to develop, and then I’ll just do that because that’s the kind of work that I want.” That’s the socialized mind.

At that stage, a socialized mind, you’re well-aware of shared agreements, shared expectations, so you’re actually able to work really well on a team, so when an Agile coach comes in and says, “We need to work on team. We need have a work agreement. We need to agree on how we’re going to do all this” — you’re right there and you’re able to do that just fine.

HS: Right. Okay. It sounds a lot — and I’m maybe taking this down the wrong rabbit hole here — but when you say that it sounds like kind of the beginning stage when I think about team dynamics into working on a Scrum team, for instance, it sounds a little bit like understanding the roles artifacts and ceremonies of working in a team and doing them well would fit within that stage, but that’s about a group, not an individual, but —

WR: Yeah, well, actually, each of these stages have a corresponding structure in an organization. There’s actually a strong tie between the mindsets of the participants in the organization and the level that the organization is at. If you were to read Laloux’s “Reinventing Organizations” where he talks about different kinds of organizations and classifies them with colors, this is the same set of stages, because one kind of mind is comfortable in a certain kind of organization, and so they’re actually very closely related.

HS: Cool. So now moving from a socialized mind, they would move to stage four, which they call a self-authoring mind?

WR: Self-authoring mind, right.

HS: Okay.

WR: This is the point where you’re more comfortable. This is what Covey would call “independent.” This is the point where you’re more comfortable driving the agenda. You’re beginning to learn to be a leader. You have your own compass and frame of reference that you use to evaluate what comes to you from the world, and you’re seeking out how to solve problems like, I’ve got a bunch of — I noticed this problem, I’m going to own that problem. I’m going to solve it. This is the kind of mind that a lot of Agile training expects or intends to encourage.

As an example, one of the things that we talk about is seeing the whole. This idea that it’s no longer acceptable that I do my work, and I hand it off to you, and I don’t care where it goes from there because I did my piece, and if your piece is late, “What’s your problem?” Right? That’s no longer acceptable. We need to look at how are we, together, delivering value to our Product Owner or our client. So we need to have an outside in sort of look. We need to be able to see the whole and think about a flow. That —

HS: So a little bit of a systems view of things.

WR: Yes. Exactly. Exactly. Systems view is a self-authoring mind kind of stage in order to do that. So when you’re asking people to do that, that’s the level of expectation that you’re asking [of] them.

Another expectation that’s at the self-authoring mind level is this idea of being self-initiating or self-correcting. So, I worked with an Agile team at a telecom, and they had stopped doing retrospectives, and I asked them, “Why aren’t you doing retrospectives anymore?” And they said, “Well, nothing ever happened.” I said, “Really? Tell me more about this because —”

HS: It’s not a great retrospective but …

WR: Right. Well, so they didn’t feel that great of an ownership over the solving of their own problems. They felt like they would identify the problems and someone else somewhere in the organization would solve the problems for them. That’s an external sort of an evaluation, that’s not an internal evaluation, and that’s actually closely related to the next thing that I would call, the next expectation, which is “self-ownership.”

If you just since I keep mentioning Covey, I’ll go back to his comment of stimulus and response, if you think about his idea that something happens to me, but I’m in control of my response, I can respond or not. The gap between stimulus and response is mine — that’s sort of a self-ownership. And that’s what we would want an Agile team to get to. We would want to say whatever organizational environment you’re in, whatever impediments you’re experiencing, we expect you to identify things in your own process that you can improve and so own that. If you can’t control it, maybe you can still influence it, so what can you do to influence the change around you, that kind of ownership. And that was different with this particular team that basically said, “Well, I found the problem. Somebody else should solve it,” and so that’s a different stage of development.

HS: And then, I see mastery up here.

WR: Yeah, so mastery is a similar thing. So the socialized mind says tell me what the standards are, tell me how to do my practice. I’ll follow them. I’ll do them well, and I’m going to essentially take an apprentice viewpoint toward my profession, right?

When we talk about technical mastery, what we’re thinking of is “I’ve learned this well enough to distinguish when to apply what standard to figure out what the best thing is in each case.” And so this is actually somewhat related to something else we use in training, the idea of Shu Ha Ri, right? So at the Shu level, you’re saying just give me the rules. I’ll learn to follow the rules. But by the time you’re at the Ri level, you’re making the rules, right? And in between is the Ha where you start playing around with the —

HS: The edges of the —

WR: …options.

HS: …roles, yeah.

WR: Exactly. Exactly. So when we’re talking about mastery, this idea that you should research a Ri stage and have some idea when you apply what rules — again that’s a self-authoring mind expectation that is difficult to do at the socialized mind stage.

HS: The next level that you’ve got is, so self-transforming mind?

WR: Right.

HS: Is anybody there? I mean, is this something that we see a lot of?

WR: Not a lot. So, Robert Kegan has done research into adult development and who’s at what stage, and so he did one study of about 500 people longitudinally and another study of over 300 longitudinally and found like less than 1% at this stage.

HS: Wow.

WR: So, it’s not frequent in the population or in … It often shows up in leaders, right? Because they’ve been able to see that.

The one expectation that I put up there is around collectively creating a vision. I put in the self-authoring mind, this idea of instituting a vision. So if you think of a leader saying, “Here’s our vision. Here’s the direction we want to go. Let’s go.” That’s a self-authoring approach, right? There is a different kind of a leader that says, “Hey, here’s the general direction I want to go, but let’s create it together. Let’s figure out what that looks like when we all put our desires and hopes into this and create something together.” That’s a more difficult thing to do.

It’s interesting here because there is something here that can be confusing. Covey talks about dependent, independent, interdependent as these sorts of stages. So first, I’m reliant on others, then I learn to be self-reliant, but then later I learn that okay, I’m self-reliant, but actually there’s a lot of value and synergy when I interact with other people. That interdependence can look like dependence. So there’s what I would call a “pre/trans fallacy”: you have to be careful to distinguish between the levels what’s really going on.

At one level, where I’d say, “Give me the vision.” Well, that’s a socialized mind approach. To graduate from that, maybe I would say, “This is the vision. Let me enlist you in it.” But at some level beyond that, you say, “Here’s the general shape of the vision, but I really want all of us together to work on this. How can we make this vision truly shared?” That’s a more difficult level of leadership.

HS: This seems really hard for people to self-assess in themselves, especially in the leadership space because I’ve witness people let clients that feel like that they’re that kind of leader, that they’re actually the kind that you would describe as a self-transforming mind: they do the action without actually doing the heart part of it. Do you see that? And how do people actually know themselves where they are?

WR: This is actually what kept me away from this field for years. Nearly a decade ago, we started talking about maturity models, and we had a big debate, and the group I was with at the time just threw out the idea of maturity models, and for years, I kept with that sort of bias because every time I saw a maturity model, I asked two questions about it. I said, 1) how does this guy who wrote this maturity actually know, like where’s his data? What’s his theory? And then 2) did he just write a model that places him at the peak? Right?

HS: Yeah. Yeah.

WR: Right?

HS: Yeah. I get it.

WR: And so most of those models out there look to me like somebody said, “Well this is how I became Agile, and obviously, I’m much more Agile than everyone else, so this is the end of the road and how I got here is how everybody got here.” So for the longest time, I looked at all maturity models with a skepticism based on “Is that really the way it happened?” It took me actually a while to be convinced that there was some reality behind Robert Kegan’s work, but he has a set of data and a clear theory that explains the transitions between it, so I’ve become convinced that there is really something there.

But, as you note, it’s really difficult to self-assess. This sort of thing is ripe for a lack of self-awareness, and for someone at one level just not knowing what they don’t know and, as a consequence, rating themselves higher. So really, the way to get this kind of information is through external feedback.

There’s actually an instrument called the “subject-object interview” that allows you to do this, but simply going to the people around you and asking them questions like “What do I really need to get better at? How can I improve in a way that would help our overall direction go better?” Those kinds of questions can give you the kind of information you need to assess this sort of thing, but it wouldn’t be something that I would sit down and try to figure out for myself.

HS: I know from my own experience, and I’ve seen it in others, is that the more I know about what I’m supposed to do or the more I know what about what I’m supposed to know, the worse that I will rate myself because now I’m aware of the gap that I have. Before, when I didn’t know that, I thought I was really good at something, and once you really get deep into it, you go, “Wow. I’m a failure,” so I rate myself — the self-assessment changes, but I’m actually growing, and I’m getting better, but my rating gets lower. There’s a saying for that, and I forgot the word now.

WR: That’s actually known is called the “Dunning-Kruger effect.”

HS: Dunning-Kruger effect, yeah.

WR: Because at a certain point, you don’t know what you don’t know, and so you rate yourself, you think, “Well, I know about 90% of what needs to be known in this area.” Actually, you just know 90% of what you’re not ignorant of. But then on the other hand, if you’re actually quite competent, you tend to assume that people around you are equally competent, so you’re probably about average. People tend to underrate or overrate themselves depending on which side of the average they are. It is an area that’s ripe for misunderstanding.

HS: So, you’ve been consulting a long time, and you said it’s taken you awhile to come to this and realize the value in this. How do you apply it? I mean, you’re working at clients. How does this resonate with them? Do you lay out to potential leaders and say, “Here are the five stages. You’re at number two. You suck.” As a consultant, how do you work with this and this knowledge now?

WR: Right. I don’t try to put people in any sort of stage.

HS: Thank you.

WR: Yes. And in fact, if you go back to Piaget and the childhood development, there’s a phenomenon he calls “horizontal décalage,” which means you reach a certain stage, but in one area of your life, and then you spend some period of time expanding your understanding of that across more areas of your life. So I don’t look at a whole person in terms of a stage. I might look at a particular situation in terms of what stage it’s reflecting.

We actually see this in Agile. You’ll get somebody that didn’t know anything about Agile. They’ll learn Agile, and then they think, “Oh, this is great,” and they start doing Agile in their software development. Then they say, “I bet I could apply this at home.” Then they teach their kids to use a Kanban so that they remember to brush their teeth and do their homework. Then they plan their wedding using a Scrum approach or whatever, and so they start applying it all across their lives.

So I really look situation to situation and try to assess what’s happening. Here’s an example of that: so I’m working with a client where there’s a significant amount of challenge in the organization around understanding what other parts of the organization want or are contributing or really mean, and so they’re really struggling to look at things from other points of view. That’s a very sort of stage three, “my tribe, I understand my people, I don’t understand those people” — and you can hear it in their language, the “us and them” — all that sort of thing happens, right?

In that particular case where I recognize that, I say to myself, well I could attempt to accommodate the stage three, but really, to do Agile well, you have to be able to put your mind in the mind of the customer, and put your mind in the mind of other groups, and so we need to stretch. A clear example of that is user stories. User stories — if you come to a group and user stories are written, “As a database system, I want blah, blah, blah,” right. Then you know, don’t really understand user stories —

HS: You haven’t gotten there.

WR: It should be in the voice of the user. So you need to see things from the voice of the customer. In that situation then, I challenge the people I’m talking to to look at things from the other point of view, because I know that doing Agile well is going to require them to do that. They’ll tell me, “Well, so-and-so thinks this thing,” and they’ll say something that no one would ever say because it portrays them in a bad light. And I will say, “Interesting. What would they say they mean by that?” and attempt to challenge to them to think about things from an outside point of view, as an example.

It’s not sort of classifying people by stage, but sort of recognizing behaviors that don’t match the expectation of an Agile mindset and attempting to help that person move in the developmental direction by exposing them to feedback or outside information, just like I was saying that you need outside information in order to make that transformation.

HS: So it seems like the human development is complex. There’s a lot of complexities in that —

WR: Absolutely.

HS: And there’s complexities in the human mind, and there seems like there’s complexity in Agile itself. Is there an alignment and a reason why that these things are that way?

WR: Yeah, so actually one way of looking at what we’ve been talking about is complexity of meaning making, like how complex your view of the world is.

In childhood, you view the world as fairly straight forward, it’s fairly simple. If you’ve got an “us and them” and sort of tribal viewpoint, you’ve got the world neatly divided. The modern world expects us to have a more complex view where we tolerate a wide variety of different ways of looking at things, and so we’re constantly increasing in complexity of mind.

This is actually part of what Agile was designed to address. We used to think that, well, we’re just going to develop software like we developed engineering. We just do our plan, then we do our design, and then we don’t have very many defects, and we’re done. It never worked out that way because it’s not that straight forward.

I used to be in civil engineering, and I can tell you that the human dimension of software and the interaction between humans and systems is far more complex, and so Agile is a way of addressing the complexity in software development and also the complexity in our modern economy, the fact that we need to figure out how to get to market fast and figure out what the customer really wants. This developmental set of stages is increasing the complexity of your thinking in the same way that Agile is increasing your capability of dealing with the complexity of development or the software development or the complexity of the market.


HS: Wow.

WR: Yeah. No, it’s been exciting for me to see these connections, although I am challenged to explain them in ways that seems pragmatic, like “What do I do next?” sort of thing.

HS: I was going to say, you seem to make, you draw really clear lines between, and they’re ambiguous lines sometimes, I realize — but you seem to see those connections. I’m thinking about the listeners that actually can’t seem to visual those connections between them and how to help explain those in a way that resonates with them. It’s deep stuff, man.

WR: Sure. Sure.

HS: It really is.

WR: From the complexity point of view, I think the simple example is if you can make a plan, consult an expert, and then… you know, consult an expert, make a plan, and then execute it, and things work? Then you’re not really dealing with a very complex situation, and we try to treat software that way. What always happened was you would show the software to somebody, and they would say, “You know, I know that’s what I said, and your requirements are probably right, but now that I see it, it’s totally not what I want.” And that’s just because that sort of approach of “we’re going to do some analysis and then we’re going to execute based on that” just doesn’t work on this space. It’s a complex space, and so Agile tools are a way to figure out how to deal with that complexity by simplifying it and reducing it, time-boxing it, setting in front of team. What we’re talking about here with developmental stage is how to expand your ability to think about the complexities that an organization or life or development bring your way.

HS: It sounds like that a client or a customer that’s really wanting to get the full benefit of this Agile adoption, this transformation — which isn’t my favorite word, but that’s the word that we use — has to think about these different stages of mindset shifts and those kinds of things. Because this isn’t like a standups, artifacts, retros — those are actions that you take. How do they grow, how do they learn in that area? And how do they know whether they’re actually on the right track or not?

WR: Right. Well, let me talk about transformation just for a second —

HS: Oh, God.

WR: …because, whatever word we use for it, one of the distinctions that I think is important is that there’s sort of this horizontal learning where I learned a new programming language, I learned a new language, I learned a new process, right? We can call that technical change or technical learning. But then there’s this sort of adaptive change, like I learned a new way of viewing the world. I learned a new way of relating with people. I’ve learned to think about things in a different way and see different things. And really, in a lot of organizations, Agile does require that and so you might use the word transformation for that, or you might call it an adaptive change or something like that.

Pragmatically, what that means [is], let’s take the example of a manager, if somebody’s reporting to you and they’ve come to you and they say, “The Product Owner is telling me what to do and why does the Product Owner get to tell me to do?” As a manager, you would say, “Well, that’s because they’re playing the role of the voice of the customer.”

But you need to recognize that the challenge this person is facing is seeing their team from the outside, seeing their team from the point of view of the organization for which the Product Owner is the representative, and so that’s a developmental challenge. How do we help this person see a little differently? What kind of feedback can we give that will help them see the importance of that role in the team.

HS: That sounds like a professional development opportunity.

WR: Yes, absolutely.

HS: How do they tie that together, for transformation even?

WR: Right. Well an experiment that I’m running with one of my clients is to do exactly that: to tie it together. So to work with a set of people and say, “What is it that you need to get better at in order for the transformation to succeed?” Because this is the thing about it. It isn’t just I learned something, and this will be successful. Each person has to change the way they think about their work and other people in order for it to be successful. You can make all the changes you want on paper, you can put people in rooms, and you can draw different org charts, and you can articulate strategic visions, but unless the people learn to relate differently and think differently and talk differently, it’s not going to be successful.

The tie-in there is to say, “Okay, for each person that we’re working with, what is it that they need to develop? What is it they need to work on for this transformation to be successful?” Maybe for one manager, they’re a micromanager, and that doesn’t work well with Agile teams, and so they need help getting themselves out of the micromanagement trap, where I do everything because my reports don’t know to do it, but of course they never learn because I tell them repeatedly how to do it, right? That’s a trap I’ve got myself in.

So maybe that’s the thing each person needs, that particular person. For each person there’s going to be something that’s going to be part of their growing edge that will help the transformation of the organization as a whole.

HS: It’s a professional development of being Agile, professional development plan towards not just learning the mechanics but of actually what is it like to being Agile, and it’s probably changed management over things that they need to start doing and stop doing as well through that. It’s interesting, I never thought about tying those learning objectives to an Agile transformation.

WR: Right.

HS: That’s deep stuff.

WR: It is, right. Yes. Because the organizations reflect the way we think about the world and relate to each other, particularly the leaders, and so when we’re changing an organization, there has to be also for that to actually happen and not just be a plan on paper. There has to be a corresponding change to mindset on the parts of the leaders and the participants.

HS: Wow.

WR: So that’s deep stuff.


For more deep stuff from William, you can email him at And to keep the learning going, don’t forget to subscribe to Agile Amped!

The post Adult Cognitive Development and the Agile Mindset appeared first on SolutionsIQ.

Categories: Companies

Remote Work – Hardware?

Growing Agile - Thu, 05/18/2017 - 15:45

Here’s the hardware we use currently use. As with tools – this changes overtime… what do you use?

Speakerphone: Perfect for conference calls which we both attend from the same location, but with remote clients. Works both as a USB speakerphone for your computer and a bluetooth speakerphone for our cell phones. Much clearer than the built in speakerphone on my iphone. We’d highly recommend this as a really cost effective good quality speakerphone. We use:

USB Headsets: These work great if we are apart and need to dial into a meeting, or only one of us is on a call. They are better than using the built in mic and speaker of our macbooks because typing noise isn’t picked up. You can go much higher end on headsets, but these work well enough for us. They don’t work if we are in the same room and on the same call though. Still looking for a headset solution for that (which is affordable). We use:

Microphone for video recordings: We use this if we record video with sound for online courses, or something similar which people will watch asynchronously. It is great at filtering out background noise like cars driving past etc. Again a great product for it’s price range. We use:

IPad Pro: We use our ipad pro to do remote sketch-noting and also as a better whiteboard tool via screen sharing. It doesn’t allow others to draw on it – but the handwriting is so clear and easy to read that everyone can easily follow.

Categories: Companies

Targetprocess v.3.11.3: User Stories will now follow their parent Feature

TargetProcess - Edge of Chaos Blog - Thu, 05/18/2017 - 08:01
User stories will now follow their parent Feature

Previously, if you moved a Feature to another Project, its User Stories did not follow the Feature to the new Project. This was fairly counter-intuitive. Starting with this release, if you move a Feature to a different Project, all of its User Stories will follow (as long as they were originally in the same Project as their parent Feature).

If you move a Feature to a Project with a different process, you will get a warning that this change might cause you to lose some custom fields.


Private Impediments have been removed

As described in this blogpost, we're removing this barely-used feature to improve performance and reduce complexity. Feel free to message our support team if you have any questions.

Fixed Bugs
  • Corrected the @user mention format for email notifications
  • Fixed the creation of a Test Plan with multiple Test Cases via REST API POST
  • The order of mandatory custom fields in Quick Add forms will now correspond to their order in entity views
  • Fixed a case where it was not possible unlink a Bug from a Test Case Run if its Test Plan Run is the child of another Test Plan Run
  • Improved the performance of Relations lookup
  • Fixed an incorrect term: When completing Team Iterations, the system would incorrectly describe them as Iterations.
Categories: Companies

Staying on Course With Agile

Leading Agile - Mike Cottmeyer - Wed, 05/17/2017 - 23:22

You may have heard that agile is just a bunch of cowboy programmers doing whatever they want; there is no rigor or discipline and best of all…NO more documentation. You may have heard about the agile zealots and that teams are full of these so called “agilistas” just spewing out code with no concern for quality and that you never know when anything is going to get done. You may have heard that others have tried some form of ‘agile’ and that “it” doesn’t work. Well fake news is everywhere these days, and misinformation about what agile is, and the notion that agile doesn’t work is a prime example.

The emotional reactions to agile can range from ‘meh’ to a vitriolic ‘it’ll never work here’. But, for organizations that are enthusiastic about making a transition and infusing more agility into their businesses, it is important to filter out the hyperbole. The facts can set you free. Becoming more agile is a journey rather than a destination, and in many ways, the path can be non-intuitive and overgrown with detritus.

Clear requirements have traditionally been an important first step to understanding the solution space and, just as importantly, an idea of how long it will take to implement it. There is a bit of hubris in this approach. Experience has shown that trying to nail down requirements at the beginning of a project—when we know the least about it—is the worst time to do so. What teams need instead is the ability to learn what a customer is trying to take care of throughout the project and make course corrections based on that emerging knowledge as it grows. Engendering the skill of making course corrections is one of the keys to the agile kingdom.

Experiments, and designing for discovery helps teams stay on course and produce better outcomes than big requirements documents and a lot of up front design. A well-groomed backlog is essential, but it does not mean that every detail is understood and articulated up front. Determining how to implement the details of a solution at the last responsible moment is encouraged because great solutions are based on the most up to date information about what is really needed rather than what we thought was needed at the outset of the project. Balancing when that information is captured and converted into team knowledge is a big differentiator between “doing Agile” and being agile.

That does not mean we don’t do any up front planning and certainly does not mean “No Documentation”. Themes, Initiatives, Epics and Stories all need elaboration and some form of memorialization so that teams can gain some collective knowledge around the outcomes that are going to be most important to customer. That documentation may be concise, and it may continue to be elaborated throughout delivery, but it should be captured in some way that communicates both the what and the why of the effort. The outcomes a customer is after is more valuable to understand than features or functionality. Requirements documents historically focus on the latter.

Far from the misperception that agile lacks discipline, done well, it is actually more rigorous than traditional approaches. Prioritization around value is not just the first step to a series of predetermined steps, but rather an ongoing guiding force as we continually refine our course toward the ultimate destination. Like an airplane navigating to Tokyo, pushed off course by winds and sometimes circumnavigating around bad weather, constant course correction produces a better result than setting a direction and hoping nothing changes along the way.

In a way, IT Leadership reminds me of my flying days. From checklists to navigation charts, pilots need documentation too. They need to know the radio frequencies with which to communicate and the protocols for doing so. And the good pilots are rigorous; they are disciplined. Now, there are some cowboy pilots out there who eschew the rules. Sometimes, unfortunately, they end up serving as a cautionary tale for others. There is an old saying about pilots, and I think it applies to IT leaders as well.

There are old pilots and there are bold pilots, but there aren’t any old, bold pilots!

So, rigor, communication and even documentation really are necessary. The best pilots have a lot of airtime and experience. They are most likely to get you safely to your destination. Indeed, for IT leaders, with large IT projects, there are similarities to flying a plane. Communication as well as both the skill of navigating and course correcting—are essential.

There are both cowboy pilots and cowboy agilistas out there. IT projects and flying can be inherently dangerous, and like so many failed IT projects, there are a plethora of failed agile experiments too. My recommendation in both cases is to look for experience. If you are considering agile, don’t listen to the “fake news”. Find a seasoned agile guide; someone with an approach that considers your environment, your business model and your customers and flexes to help you make the most of your transformation. Experience matters and the success of your journey may just ride on who you’ve chosen to help you navigate the course.

The post Staying on Course With Agile appeared first on LeadingAgile.

Categories: Blogs

Why we’re excited about Gene Kim’s upcoming keynote at the SAFe Summit

Agile Product Owner - Wed, 05/17/2017 - 17:50

Few thought leaders in the IT space can match the global influence Gene Kim has had in helping organizations radically improve how technology-based capabilities are developed.

Gene’s ‘ding in the universe’ began with The Phoenix Project, that once-you-start-reading-it-you-can’t-put-it-down novel that had all of us wondering how Gene and his co-authors managed to know so much about the people we worked with and the challenges we had all faced throughout our individual journeys in IT. What started as a worldwide conversation about a book has turned into a movement, providing leaders and practitioners with a unifying blueprint for how software and systems will be developed, deployed, enhanced, and supported for years to come.

It has been my tremendous honor to have known Gene personally for several years. I met him at a small dinner gathering in Washington DC, and was amazed at his humility and genuine interest in my stories of how government agencies were wrestling with the shift to Lean-Agile product development. We have continued our conversation and our friendship ever since. His encouragement and curiosity throughout my doctoral journey was more meaningful to me than he will ever know. It was a highlight of my career to be invited by Gene to share the insights of my research into transformational leadership and organizational change at the DevOps Enterprise Summit in San Francisco in 2016, and again this year at the DOES conference in London.

All of us at Scaled Agile are thrilled to have Gene as a keynote speaker for this year’s SAFe Summit. Gene’s wisdom and insights into the global DevOps conversation reflected in The DevOps Handbook have been immensely helpful as we have expanded our discussion of DevOps in the next update to SAFe. In his Summit presentation, Gene will share the top lessons learned in his study of high-performing technology organizations, as well as the top principles and patterns, and how large, complex organizations are successfully adopting DevOps culture and work practices.

The lineup for our gathering in October was already powerful, but with the addition of Gene’s voice this year’s Summit just became a must-not-miss event! We look forward to seeing you there.

—Dr. Steve Mayner
SPCT and Senior Consultant

Categories: Blogs

Scrummish to Scrumban

Scrum Expert - Wed, 05/17/2017 - 16:42
Shoddy software quality, disgruntled customers, missed deadlines… Such is daily life in many software companies. But there exists a better way. This presentation tells a story of turning around...

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

Knowledge Sharing

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