Skip to content

Feed aggregator

Insights into Agile Transformation Success, Part 2

Agility at the Product, Delivery & Execution Levels

Contributors: Mike Dwyer and Richard Lowery

SolutionsIQ is passionate about helping enterprises successfully kick off and execute large-scale Agile Transformations. In our first blog article on this topic, we introduced our five-dimension model for setting up an Agile Transformation for success, and we looked into the first two dimensions: Leadership and Organization. In this continuation of that discussion, we’d like to iterate on this a bit further with the remaining three dimensions of a successful Agile Transformation: Product, Delivery and Execution.

Product

We have observed a direct correlation between the level of investment in the Product Owner role and the overall degree of success in achieving the desired outcome of an Agile Transformation. The correlation between Product Ownership and Agile Product Management, however, is not one-to-one, as traditional product and portfolio management roles change in an Agile enterprise. In our findings, enterprises

that invest heavily in product ownership and product management skillsets tend to have the most enduring and pervasive success with Agile Transformation. In particular, Product Owners champion the new Scrum roles of the teams they support, which includes embracing the responsibilities of their own role. Some POs also invest in training and coaching people to be successful in their new roles. A solid product ownership foundation is critical because only by getting the basics down can the enterprise unlock certain higher-order capabilities, including portfolio management, product vision and product roadmaps.

These product management best practices are crucial for many organizations because often the people fulfilling the Product Owner role have no formal training or background in classic product management. Focusing on creating a clear, effective working relationship between Product Owners and Product Managers is another indicator of success for Agile transformation.

Delivery

Delivery focuses on the practices and processes of teams and groups of teams delivering a project, program, or product. This includes how well individual teams and sets of teams are using Agile frameworks like Scrum and Kanban, how Lean is being applied to other aspects of value streams, and the enterprise’s success with Agile scaling patterns and frameworks like LeSS and SAFe.

In our findings, the enterprises succeeding in their Agile transformation pay much attention to getting the core Agile foundations right from the start. This is critical given that key success indicators such as release planning and scaling patterns are all built on top of solid foundations of Agile-Lean knowledge of Scrum, Kanban, and XP. Enterprises that have lasting success with Agile Transformation typically have a small army of highly effective ScrumMasters who are evangelizing both the core foundations of the frameworks as well as the overall goals for that enterprise’s Agile transformation.

It is critical to focus heavily on the Agile Foundations at the team level.  Many enterprises will first introduce Agile Coaching at the team level in a pilot program so they can first understand the sets of impediments that are likely to prevent team success. Then when that is understood clearly and the team starts to see change in the right direction, the organization can build upon this success with a much broader team coaching plan. Eventually the enterprise layers on top a scaling solution which will allow the organization to have delivery success on a large scale.

One company we recently worked with showed a lot of capability at the Delivery layer and can serve as a model for other organizations to emulate.  The company came to the realization that it was critical to invest heavily in foundational Agile training for teams. They decided to offer Agile coaching for teams and to creating a cadre of highly effective ScrumMasters.  In addition, they had dedicated teams with focus and little to no context switching.  These investments in laying down a firm Agile foundation and investing Agile teams allows them to execute multi-team release planning events today with a high degree of effectiveness and predictability.

Execution

For every company that has had success with the Delivery side of an Agile transformation, there are just as many who aren’t seeing that success because they haven’t made the commitment to transform into a modern Agile software development shop. This is why we put so much emphasis on technical execution in our Agile transformation strategy. Simply put, Execution is what enable the enterprise to see faster delivery cycles, higher quality with fewer (if any) defects, etc. Other benefits seen include a higher degree of innovation, higher collaboration and transparency, and more dependable delivery estimations. The technical practices that yield these results stem mainly from Extreme Programming (XP), including test-driven development with test automation, refactoring, code smells, technical debt remediation.

In our findings, the organizations investing heavily in test automation are having large-scale success with Agile. They also ensure that:

  • Software engineering best practices such as unit testing are being used all the time.
  • Technical debt is being tracked and time is set aside to remediate this debt.
  • Delivery progress is transparent and radiated to all stakeholders.

Clients seeing the most success have also have made investing in their software development and testing environments a priority. In the future, through such an investment, they will be able to use higher-order modern software engineering practices such as Unit Test Driven Development, Acceptance Test Driven Development (ATDD), pair programming, mob programming, and self-organized, cross-functional teams. These high-performance practices are made possible directly and indirectly from transformative changes at the organizational and leadership levels. A higher expectation of peer involvement, knowledge sharing, and collaboration within teams is a key element of Agile transformation, which gives rise to an improved sense of community that expands well beyond the development teams.

Summary

Looking back on 2016, SolutionsIQ continues to be thrilled by how many of our clients have achieved enduring and pervasive success with their Agile transformations. Very little of that success was pure luck.  In every example of success, there was a deliberate and focused strategy for how to establish and execute the transformation to Agile. To this end, we have identified five key dimensions in a successful Agile Transformation strategy: Leadership, Organization, Product, Delivery and Execution. Within each of these five dimensions there are a number of common patterns for success. Enterprises that are succeeding in their Agile transformation are putting emphasis on the following areas:

 

If your enterprise is about to start your own Agile Transformation in 2017, or you’re concerned that you have not been realizing the long-lasting success you had originally hoped for from your Agile Transformation, consider replicating some of these success patterns as part of your overall strategy and roadmap.

Be the first to get your hands on the white paper “Insights into Agile Transformation Success” — sign up for our AgileUp newsletter!

The post Insights into Agile Transformation Success, Part 2 appeared first on SolutionsIQ.

Categories: Companies

Groundhog Day at the Agile Transition Initiative

Agile Complexification Inverter - Mon, 02/20/2017 - 22:21
Now that everyone knows about Bill Murray's movie Groundhog Day - I love February 2nd.  It's my favorite, most enjoyable, beloved, cherished, esteemed day of the year.  And I don't need to tell you again how many LIKES I give this redundant day... so on to the story.

Bill & Groundhog
Well this happened about ten years ago, and about 6 years ago, or maybe it was 4 years past, and seems like we did this about 24 months ago...  or it could be today!

The Agile Transition Initiative at the company has come upon an inflection point (do ya' know what that is...  have you read Tipping Point?).  I'm not exactly sure of it's very precise date... but Feb. 2nd would be the perfect timing.   The inflection has to do with which direction your Agile Transition Initiative takes from this point into the future.   Will it continue on it's stated mission to "transform" the organization?  Or will it stall out and revert slowly to the status quo?

How do I recognize this perilous point in the agile trajectory?  Well there are several indications.  But first we must digress.



Punxsutawney Phil Says more Winter in 2017In this story we will use the germ theory as a metaphor.  Germ theory came about in about ... (wait - you guess - go ahead ...  I'll give you a hundred year window... guess...). That's right! "The germ theory was proposed by Girolamo Fracastoro in 1546, and expanded upon by Marcus von Plenciz in 1762."  Wow, we've know about these little buggers for a long time.  And we started washing our hands ... (when...  correct -again).  "The year was 1846, and our would-be hero was a Hungarian doctor named Ignaz Semmelweis."  So right away business (society) started using a new discovery - a better way to treat patients.... or well it took a while maybe a few months, or maybe  more than 300 years.

But back to the metaphor - in this metaphor the organization will be like a human body and the change initiative will take the roll of a germ.  The germ is a change introduced to the body by some mechanism we are not very concerned with - maybe the body rubbed up against another body.  I hear that's a good way to spread knowledge.

We are interested in the body's natural process when a new factor is introduced.  What does a body do?  Well at first it just ignores this new thing - heck it's only one or two little germs, can't hurt anything - (there are a shit load of germs in your body right now).  But the germs are there to make a home - they consume energy and reproduce (at this point lets call it a virus - meh - what the difference?).  So the virus reproduces rapidly and starts to cause ripples... the body notices this and starts to react.  It sends in the white-blood cells - with anti-bodies.  Now I don't understand the biological responses - but I could learn all about it... but this is a metaphor and the creator of a metaphor may have artistic license to bend the truth a bit to make the point.  Point - WHAT IS THE POINT?

The point is the body (or organization) will have a natural reaction to the virus (change initiative) and when the body recognizes this change it's reaction (natural - maybe call it subconscious - involuntary).  Well let's just say it's been observed multiple times - the body tries very hard to rid itself of the unwanted bug (change).  It may go to unbelievable acts to get rid of it - like tossing all it's cookies back up - or squirting all it's incoming energy into the waste pit.  It could even launch a complete shutdown of all communication to a limb and allow it to fester and die, hopefully to fall off and not kill the complete organism.  Regaining the status quo is in the fundamental wiring of the human body.  Anything that challenges that stasis requires great energy to overcome this fundamental defense mechanism.

[Pop the stack.]  So back to the indicators of the tipping point in agile transitions.  Let's see if our metaphor helps us to see these indications.  The tossing of cookies - check.  That could be new people hired to help with the change are just tossed back out of the organization.  The squirts - check.  That is tenured people that have gotten on board with the change being challenged by others to just water it down... make it look like the things we use to do.  Heck let's even re-brand some of those new terms with our meanings - customized for our unique situation - that only we have ever seen, and therefore only we can know the solutions.  Folks, this is called the Bull Shit Reaction.

Now imagine a limb of the organization that has adopted the new way - they have caught the virus.  There is a high likely hood that someone in the organization is looking at them a "special".  A bit jealous of their new status and will start hoarding information flow from that successful group.  Now true that group was special - they attempted early transition and have had (in this organizations realm)  success.  Yet there was some exception to normal business process that made that success possible.  How could we possibly reproduce that special circumstance across the whole org-chart?  Maybe we just spin them off and let them go it alone - good luck, now back to business.

What's a MIND to do with this virus ridden body and all these natural reactions?

Well we are at an inflection point... what will you do?
Which curve do you want to be on?  - by Trail Ridge Consulting
See Also:

The Fleas in the Jar Experiment. Who Kills Innovation? The Jar, The Fleas or Both? by WHATSTHEPONT


Categories: Blogs

Does SAFe apply to small teams?

Agile Product Owner - Mon, 02/20/2017 - 18:20

Recently, I heard from my colleague and long-time collaborator, Juha-Markus Aalto. Back when we were in the Agile working group trenches at Nokia, Juha-Markus was responsible for some of the initial, critical thinking behind what became SAFe. Specifically, he helped define the “requirements metamodel”, which arsm-med-largee the elements and relationships throughout the important system definition artifacts in the Framework. (Epics, Features, Stories, associations with tests and acceptance criteria, etc.) In turn, this helped unlock the ability to scale Agile from the team, to program to portfolio level. I have always appreciated his deep thinking, technologic competence, and humble manner.

Juha-Markus is now in a growth company Qentinel, and is applying his creative thinking as the leader of Product Development . His new team is still at the “S size” but if the company grows as planned, the team will likely grow as well. Even this small team faces the multi-project challenge as it delivers software to several customer specific projects, which requires common planning and portfolio prioritization. Juha-Markus is leveraging the concepts behind SAFe in his S-sized team. Of course, it works. But just how it works is proving to be an interesting topic, which Juha-Markus describes in his new blog post.

We would love to hear your comments on this article, as I think it could provide sufficient benefit to turn into a SAFe guidance article. For that, we require some additional opinions and peer review, so please ‘peer away.’

Stay SAFe!

-Dean and the Framework team

 

Categories: Blogs

Design by contract using GraphQL

Xebia Blog - Mon, 02/20/2017 - 18:20
When interfacing between systems it is good practice to think about the interface design prior to developing the systems. GraphQL can be a useful tool to write down these design decisions using its schema definition language. Even when you are not using GraphQL itself in production. GraphQL’s schema can be used to generate a mock
Categories: Companies

Agilia, Olomouc, Czech Republic, March 27-31 2017

Scrum Expert - Mon, 02/20/2017 - 09:00
Agilia is the Central European Conference taking place in Olomouc (Czech Republic) that discusses Agile approaches. Local and international Scrum experts and Agile professionals from the Czech Republic, Slovakia, Hungary, Europe and overseas will provide ideas and inspiration, speeches, case studies and workshops. In the agenda of the Agilia conference you can find topics like “Valuable Agile Retrospectives”, “Clash of Cultures: What Agile Managers Can Do to Survive”, “Enterprise Product Ownership – Field Experiences”, “Leading an Agile Transformation at Scale”, “The Heart of the Team: From the Battle Field to Barbados”, “Creating Winning Teams”, “The Principles of Product Development Flow: Second Generation Lean Product Development”, “Facilitation for Agilists and Scrum Masters”, “How Mindfulness Enables Agile Teams to Create Better Solutions?”, “Practical Tools to improve LEAN and Agile processes”, “Value Planning in a Lean and Agile Way for Managers”, “Nuggets for your Continuous Improvement Journey”, “Retrospective – On a three year large scale agile adoption”, “Agility for the whole organization”, “You are messing up with people’s lives – From burnout to #NoEstimates”, “How to Write Effective Requirements in an Agile Environment”. Web site: http://agiliaconference.com/ Location for the Agilia conference: Olomouc, Czech Republic
Categories: Communities

Neo4j: Analysing a CSV file using LOAD CSV and Cypher

Mark Needham - Mon, 02/20/2017 - 00:39

Last week we ran our first online meetup for several years and I wanted to wanted to analyse the stats that YouTube lets you download for an event.

The file I downloaded looked like this:

$ cat ~/Downloads/youtube_stats_pW9boJoUxO0.csv 
Video IDs:, pW9boJoUxO0, Start time:, Wed Feb 15 08:57:55 2017, End time:, Wed Feb 15 10:03:10 2017
Playbacks, Peak concurrent viewers, Total view time (hours), Average session length (minutes)
348, 112, 97.125, 16.7456896552, 

Country code, AR, AT, BE, BR, BY, CA, CH, CL, CR, CZ, DE, DK, EC, EE, ES, FI, FR, GB, HU, IE, IL, IN, IT, LB, LU, LV, MY, NL, NO, NZ, PK, PL, QA, RO, RS, RU, SE, TR, US, VN, ZA
Playbacks, 2, 2, 1, 14, 1, 10, 2, 1, 1, 1, 27, 1, 1, 1, 3, 1, 25, 54, 1, 4, 6, 8, 1, 1, 1, 1, 1, 23, 1, 1, 1, 1, 1, 1, 2, 6, 22, 1, 114, 1, 1
Peak concurrent viewers, 2, 1, 1, 4, 1, 5, 1, 1, 0, 0, 11, 1, 1, 1, 2, 1, 6, 25, 1, 3, 3, 2, 1, 1, 1, 1, 1, 9, 1, 1, 0, 1, 0, 1, 1, 3, 7, 0, 44, 1, 0
Total view time (hours), 1.075, 0.0166666666667, 0.175, 2.58333333333, 0.00833333333333, 3.01666666667, 0.858333333333, 0.0583333333333, 0.0, 0.0, 8.69166666667, 0.8, 0.0166666666667, 0.0583333333333, 0.966666666667, 0.0166666666667, 4.20833333333, 20.8333333333, 0.00833333333333, 1.39166666667, 1.75, 0.766666666667, 0.00833333333333, 0.15, 0.0333333333333, 1.05833333333, 0.0333333333333, 7.36666666667, 0.0583333333333, 0.916666666667, 0.0, 0.00833333333333, 0.0, 0.00833333333333, 0.4, 1.10833333333, 5.28333333333, 0.0, 32.7333333333, 0.658333333333, 0.0
Average session length (minutes), 32.25, 0.5, 10.5, 11.0714285714, 0.5, 18.1, 25.75, 3.5, 0.0, 0.0, 19.3148148148, 48.0, 1.0, 3.5, 19.3333333333, 1.0, 10.1, 23.1481481481, 0.5, 20.875, 17.5, 5.75, 0.5, 9.0, 2.0, 63.5, 2.0, 19.2173913043, 3.5, 55.0, 0.0, 0.5, 0.0, 0.5, 12.0, 11.0833333333, 14.4090909091, 0.0, 17.2280701754, 39.5, 0.0

I want to look at the country specific stats so the first 4 lines aren’t interesting to me:

$ tail -n+5 youtube_stats_pW9boJoUxO0.csv > youtube.csv

I then put the youtube.csv file into the import directory of Neo4j and wrote the following query to return a row representing each country and its score for each of the metrics:

load csv with headers from "file:///youtube.csv" AS row
WITH [key in keys(row) where key <> "Country code"] AS keys, row, row["Country code"] AS heading
UNWIND keys AS key
RETURN key AS country, heading AS key, row[key] AS value

╒═════════╤═══════════╤═══════╕
│"country"│"key"      │"value"│
╞═════════╪═══════════╪═══════╡
│" SE"    │"Playbacks"│"22"   │
├─────────┼───────────┼───────┤
│" GB"    │"Playbacks"│"54"   │
├─────────┼───────────┼───────┤
│" FR"    │"Playbacks"│"25"   │
├─────────┼───────────┼───────┤
│" RS"    │"Playbacks"│"2"    │
├─────────┼───────────┼───────┤
│" LV"    │"Playbacks"│"1"    │
└─────────┴───────────┴───────┘

Now I want to create a node representing each country and create a property for each of the metrics. Since the property names are going to be dynamic I’ll make use of the APOC library which I drop into my plugins directory. I then tweaked the query to create the nodes:

load csv with headers from "https://dl.dropboxusercontent.com/u/14493611/youtube.csv" AS row
WITH [key in keys(row) where key <> "Country code"] AS keys, row, row["Country code"] AS heading
UNWIND keys AS key
WITH key AS country, heading AS key, row[key] AS value
MERGE (c:Country {name: replace(country, " ", "")})
WITH *
CALL apoc.create.setProperty(c, key, toInteger(value))
YIELD node
RETURN COUNT(*)

We can now see which country provided the most viewers:

MATCH (n:Country) 
RETURN n.name, n.Playbacks AS playbacks, n.`Total view time (hours)` AS viewTimeInHours, n.`Peak concurrent viewers` AS peakConcViewers, n.`Average session length (minutes)` AS aveSessionMins
ORDER BY playbacks DESC
LIMIT 10

╒════════╤═══════════╤═════════════════╤═════════════════╤════════════════╕
│"n.name"│"playbacks"│"viewTimeInHours"│"peakConcViewers"│"aveSessionMins"│
╞════════╪═══════════╪═════════════════╪═════════════════╪════════════════╡
│"US"    │"114"      │"32"             │"44"             │"17"            │
├────────┼───────────┼─────────────────┼─────────────────┼────────────────┤
│"GB"    │"54"       │"20"             │"25"             │"23"            │
├────────┼───────────┼─────────────────┼─────────────────┼────────────────┤
│"DE"    │"27"       │"8"              │"11"             │"19"            │
├────────┼───────────┼─────────────────┼─────────────────┼────────────────┤
│"FR"    │"25"       │"4"              │"6"              │"10"            │
├────────┼───────────┼─────────────────┼─────────────────┼────────────────┤
│"NL"    │"23"       │"7"              │"9"              │"19"            │
├────────┼───────────┼─────────────────┼─────────────────┼────────────────┤
│"SE"    │"22"       │"5"              │"7"              │"14"            │
├────────┼───────────┼─────────────────┼─────────────────┼────────────────┤
│"BR"    │"14"       │"2"              │"4"              │"11"            │
├────────┼───────────┼─────────────────┼─────────────────┼────────────────┤
│"CA"    │"10"       │"3"              │"5"              │"18"            │
├────────┼───────────┼─────────────────┼─────────────────┼────────────────┤
│"IN"    │"8"        │"0"              │"2"              │"5"             │
├────────┼───────────┼─────────────────┼─────────────────┼────────────────┤
│"IL"    │"6"        │"1"              │"3"              │"17"            │
└────────┴───────────┴─────────────────┴─────────────────┴────────────────┘

The United States in first unsurprisingly followed by the UK, Germany, and France. We ran the meetup at 5pm UK time so it was a friendly enough time for this side of the globe but not so friendly for Asia or Australia so it’s not too surprising we don’t see anybody from there!

For my last trick I wanted to see the full names of the countries so I downloaded the 2 digit codes for each country along with their full name.

I then updated my graph:

load csv with headers from "file:///countries.csv" AS row
MATCH (c:Country {name: row.Code})
SET c.fullName = row.Name;

Now let’s re-run our query and show the country fullnames instead:

MATCH (n:Country) 
RETURN n.fullName, n.Playbacks AS playbacks, n.`Total view time (hours)` AS viewTimeInHours, n.`Peak concurrent viewers` AS peakConcViewers, n.`Average session length (minutes)` AS aveSessionMins
ORDER BY playbacks DESC
LIMIT 10

╒════════════════╤═══════════╤═════════════════╤═════════════════╤════════════════╕
│"n.fullName"    │"playbacks"│"viewTimeInHours"│"peakConcViewers"│"aveSessionMins"│
╞════════════════╪═══════════╪═════════════════╪═════════════════╪════════════════╡
│"United States" │"114"      │"32"             │"44"             │"17"            │
├────────────────┼───────────┼─────────────────┼─────────────────┼────────────────┤
│"United Kingdom"│"54"       │"20"             │"25"             │"23"            │
├────────────────┼───────────┼─────────────────┼─────────────────┼────────────────┤
│"Germany"       │"27"       │"8"              │"11"             │"19"            │
├────────────────┼───────────┼─────────────────┼─────────────────┼────────────────┤
│"France"        │"25"       │"4"              │"6"              │"10"            │
├────────────────┼───────────┼─────────────────┼─────────────────┼────────────────┤
│"Netherlands"   │"23"       │"7"              │"9"              │"19"            │
├────────────────┼───────────┼─────────────────┼─────────────────┼────────────────┤
│"Sweden"        │"22"       │"5"              │"7"              │"14"            │
├────────────────┼───────────┼─────────────────┼─────────────────┼────────────────┤
│"Brazil"        │"14"       │"2"              │"4"              │"11"            │
├────────────────┼───────────┼─────────────────┼─────────────────┼────────────────┤
│"Canada"        │"10"       │"3"              │"5"              │"18"            │
├────────────────┼───────────┼─────────────────┼─────────────────┼────────────────┤
│"India"         │"8"        │"0"              │"2"              │"5"             │
├────────────────┼───────────┼─────────────────┼─────────────────┼────────────────┤
│"Israel"        │"6"        │"1"              │"3"              │"17"            │
└────────────────┴───────────┴─────────────────┴─────────────────┴────────────────┘

And that’s the end of my analysis with no relationships in sight!

The post Neo4j: Analysing a CSV file using LOAD CSV and Cypher appeared first on Mark Needham.

Categories: Blogs

Leadership Shootout at the Agile2017 corral

Agile Complexification Inverter - Mon, 02/20/2017 - 00:36
Derek "QuikDraw" Lane & I proposed this session (2 sessions actually) for the Agile2017 conference.  Wonder if you'd like to come play in the OK Corral with us?

SlideShare DeckHere's how it might go down...  Agile2017 Submission # 5835

And if you're interested... comment on this slide deck...  it's not the final answer.  In fact we may be sneaking bigger guns in to the corral under our dusters...

SlideShare deck

Abstract:

Leadership Style Shoot Out :: Which style best works for this context - how will you recognize it?


Where do you Stand

Let's survey the audience's Leadership styles/preferences - we will use a standard reference tool (or maybe just make it up on the fly). Getting the participants up and moving and interacting with each other and the sub-set of leadership styles described on the four flip charts in the corners of the room. We will play a few rounds of the game Constellations. This warm up exercise will most likely bring up some great question on terms and concepts, which we will answer as a group.


Examples of Models & Theories

We will present several models and approaches of Leadership - via Poster Presentations (previous done posters for models of Leadership: Examples: Situational Leadership II, Leader-Member Exchange Theory, Path-Goal Theory, Servant Leadership, etc.) compare and contrast theories of leadership with other leadership approaches: ( Situational, Skills, Style, Trait - also summarized on posters). Gathering insights from participants on experiences with these various leadership styles/traits. Using some famous examples from history and common known examples (JFK, Nixon, Washington, John Wayne, Neil Armstrong, etc).


Review of Literature

We will present a library of books (10 - 30 leadership books) to loan out for the next few days of the conference - participants wishing to come to next session (2 days later) will preform a poster book report on the topics of interest with their small group on the books best topics during the 2nd session. This technique is ripped off from my mentor Sivasailam Thiagarajan (http://www.thiagi.com), I'm sure he will not sue us. This game however is going to require longer than 75 min. to get value - so I'm proposing a radical new idea for conference session - a follow up session scheduled later in the week for the sub-set of participants that choose to participate in this "home-work assignment".

In the 2nd session we will organize the posters - book reviews and give each group/team about 10 min. to present and then a few min. for audience Q&A. Largely dependent on the number of small teams wishing to participate; wishing to go in depth on a topic and learn about that aspect of leadership. Then leave time for a debrief of both sessions.


Information for Program Team:

We are requesting something VERY RADICAL - 2 sessions - for ONE topic - the first session will set the hook: interest a sub set of participants to commit to the second session (the book-review report back poster extravaganza session later in the week).

First session on Monday or Tuesday; second session on Thursday or Friday - link them in the catalog with an "**" and note.

Each session will be independent enough that participant that do not want to attend the other will be carried along with the enthusiastic games of the others that have attended both. Interesting and Learning will be available for all - regardless of attendance of both sessions.


Prerequisite Knowledge:

none really - however we assume many people have been part of a group and have seen many forms of leadership in many different context


Learning Outcomes:

- Awareness of several views of Leadership and Management
- Knowledge of multiple theories of leadership
- develop a lexicon of terms to discuss leadership behaviors
- experience being an emergent leader in a group with a specific objective
- Understanding that styles of leadership change over time throughout history
- Ways to measure effectiveness of leadership (via the fellowship of followers)
- Assessment tools and models to take home and try on your leaders





Categories: Blogs

A look at Six Years of Blogging Stats

Agile Complexification Inverter - Sun, 02/19/2017 - 05:09
What do you get from six years of blogging about Agile/Scrum and your continued learning experiences?

Stats from Agile Complexification Inverter blog site

Well the stats are just one insignificant measure of what one gets from writing about their experience.

The bad artist imitate, the great artist steal.The more meaningful measures have been seeing some of these articles and resources put into practice by other colleagues, discussion that have happened (off line & sometimes in comments or twitter, etc.) with readers that require me to refine my thinking and messaging of my thinking.  Interestingly some times seeing a resource that you have created being "borrowed" and used in another persons or companies artifact without attribution is both rewarding and a bit infuriating.  I like that the concept has resonated well with someone else and they have gone to the trouble of borrowing the concept, and repeating or improving or repurposing the concept.

Let me borrow someone else's concept:  "The Bad Artist Imitate, the GREAT Artists Steal." -- Banksy


Most of all the collection of articles are a repository of resources that I do not need to carry around in my 3-4 lbs of white & grey matter.  I can off-load the storage of concepts, research pointers and questions to a semi-perminate storage.  This is a great benefit.

Categories: Blogs

Book Review: The Wisdom of Teams

Agile Complexification Inverter - Sun, 02/19/2017 - 05:09


Introduction:  What We Have Learned
Originally written in 1993, this edition written in 2003 has additional insights from 10 years of working with teams.  The authors see more pragmatism on the subject, less thoughtless rushes to a fad movement.  Top leaders are seeing that teams also apply to themselves, at the top of the business.  They see the core aspect as discipline, not the management fad du jour.  The discipline for team performance has 6 basics: team size, complementary skills, common purpose, performance goals, commonly working agreements, and mutual accountability.  The desire to be a team is not sufficient - one must have performance centric outcomes as the objective.  Leadership is more important at the beginning - but not the primary determinant of success.  Most organizations have untapped potential in team performance.  The organizations performance ethic makes the difference between one-off success and widespread organizational team performances.
The authors develop an explicit terminology, to distinguish commonly misunderstood phrases when discussing groups and teams.  The Y-Chart (p. XXI) helps explain the taxonomy of groups (Effective Group vs Performance Units; Single-Leader Unit vs Real Team).  They define an abstract Team Performance Curve, noting time as the major factor in achieving high (extra-ordinary) performance.  The decision of which type of team; single-leader unit vs team is dependent upon 3 factors: need for collective work products integrated in real time by two or more people, shifting leadership roles for situational awareness, need for mutual accountability in addition to individual accountability.  Setting outcome-based goals is essential to achieving high performance (as apposed to activity-based goals).  Real teams require more time and leadership capacity than single-leader units.  Process support for multiple team opportunities across broad programs is essential to scale the team success from one-to-many.
Prologue:  A Note About What to Expect
The book notes the obvious concepts but also the subtle nature of language used to describe the concepts are required to be precise in defining the discipline.  The authors find that it is difficult to apply common sense to teams.  Expect failure when: building the team for its own sake is the goal (rather that demanding performance challenges), the discipline of “team basics” is overlooked, many areas for teams are left unexplored in organizations (teams: recommend things, do things, run things), teams at the top of organizations are the most difficult, individual accountability is the norm (as apposed to team/group accountability).
Uncommon-sense findings: strong performance standards seem to spawn more teams than teaming-for teaming sake; high-performance teams are extremely rare; hierarchy and teams go together well; teams naturally integrate performance and learning; “teams are the primary unit of performance for increasing numbers of organizations” (p. 5).
Part One:  Understanding Teams
Focusing on Team Basics - figure 1-1 (p. 8)
Apex:  Performance Results; Collective Work products; Personal GrowthSides:  Skills (Performance results - Collective work products) Accountability ( Performance results - Personal growth) Commitment ( Collective work product - Personal growth)Internal:  Skills - Problem solving, technical function, interpersonal Accountability - Mutual, team size, individual Commitment - Specific goals, common approach, meaningful purpose
Chapter 1:  Why Teams?
The authors have learned that although many executives understood the argument for using teams many didn’t extract the real potential from the teams or the opportunities to use teams.  Many times because of unwarranted assumptions and poor knowledge.Key lessons:
  • “Significant performance challenges energize teams regardless of where they are in an organization.”  Performance is the primary objective.  A team is the means - not the end.
  • “Organizational leaders can foster team performance best by building a strong performance ethic rather than by establishing a ream-promoting environment alone.”  Focus on customer satisfaction performance rather than teamwork performance.
  • “Biases toward individualism exist but need not get in the way of team performance.”  Turn individualism, self-preservation, and self-centered objectives to the benefit of the team.
  • “Discipline - both within the team and across the organization - creates the conditions for team performance.”  “Groups become teams through disciplined action.  They shape a common purpose, agree on performance goals, define a common working approach, develop high levels of complementary skills, and hold themselves mutually accountable for results.”

Teams are made up of individuals with complementary skills - build on strengths, not to cover weakness.  Define clear goals, via team communication. Build real-time problem solving skills and initiative, allow adaptive behavior.  Provide social dimension to enhance work - teams fundamental nature are people interactions.  Fun is part and parcel of the process - encourage it.
Resistance to teams come from 3 primary concerns: ”lack of conviction”, “personal discomfort and risk”, and “weak organization performance ethics” (p 21-23). 
Teams do not solve all problems, they are not the answer to every problem.  They require discipline and practice.  Organization culture may be opposed to teams if a strong individualistic performance is reward in spite of team performance.
Chapter 2:  One Team: A Story of Performance
As a basic unit of performance a team blends the knowledges, skills and abilities of several people strengthening the overall performance of individuals.  Many people having once experienced the power of a high performing team long for the experience again.  Burlington Northern launched the Intermodal Rail era after deregulation in 1981.  Largely the result of a core team of 7 individuals, with an extend group of 45 people.  This team was largely self selective, all were interested in the new prospects of intermodal rail and saw the value even in face of large corporate resistance and hostility.   The team started small and grew as needed, bringing in and fostering the required skills.  A positive attitude that the goal was possible was shared by all.  Hard work and long hours were the norm for the group.  When the group’s proposal was approved but with the worst pilot project locations the group saw the opportunity to prove the concept and jumped right into it.  The core group shared leadership roles and had strong affinity of tacit information on specific skill sets.  They assumed a ask for forgiveness rather than permission attitude, and resolved impediments quickly.  The results was a change in the business model for the industry, intermodal rail is now common place and well established business process for the rail industry. 
Ch 3 Team Basics A Working Definition and Discipline
Teams are a “powerful vehicle for performance” (p. 43)  many companies are embracing teams as a unit of performance.  There are differences in understand of what a team is and what constitutes a performant team.   Teams work well when they have specific results to achieve, and the performance ethic of the organization demans those results.
“A team is a small number of people with complementary skills who are committed to a common purpose, performance goals, and approach for which they hold themselves mutually accountable.” (p. 45)
Small number - in the Agile community we say 7 +/- 2  ( 5 - 9 members).  Reasoning is the tacit knowledge of each other (the group) and the intercommunication of the team.  The larger the number the lower the accountability for success.  Large numbers have logistical problems not seen in smaller groups (space to meet, etc.).  See Also: Choosing the Team Size in Scrum by Agile Pain Relief
Scrum (software development process) offers a way to scale teams to very large (hundreds) numbers.
Complementary skills - we call this a cross-functional team.  A team must have a person with the required skills to solve the problem, and it will take many skills to solve most any complex problem.   Many successful teams realize they lack certain skills, and become self reliant on learning or acquiring the skill set.
Committed to common purpose and performance goal.  Teams must see the purpose for their existence, be motivated to achieve the goal.  The best teams spend significant time discussing their purpose, reshaping it and refining that purpose over their lifetime.
Committed to a common approach.  Agreement on the approach, process to solve the problems is a key,  they may spend considerable time on this issue also. 
Mutual accountability.  Teams must hold each other accountable for the achievement of the goal, the quality of the products, and the process.  They must be capable of defining their own standards for performance and encouraged to raise the bar.  

Ch 5 The Team Performance Curve
A team does not start out at super high performance, it takes time to reach this goal.  Many teams never reach their potential.  Experts say that if a team does reach high-performance that it should not be disbanded but kept together, and given a new purpose.  The performance curve describes this growth to high-performance.
Work groups are not teams, though they may develop into a team.  One difference is the focus either on team performance or individual performance & accountabilities.
Pseudo-teams never agree on purpose, or accountability of the group, they get stuck in rituals and avoid rather than engage each other.

Ch 8  Teams, Obstacles and Endings:  Getting Unstuck
Every team will encounter obstacles, high-performing teams develop tools for overcoming these obstacles.  Teams lower of the performance curve may need help to over come obstacles of all natures.  Teams may become stuck, and not develop the tools to resolve their obstacles, then it is time for serious help.  Stuck teams: lack energy, or enthusiasm, have a sense of helplessness, lack identity, lack purpose, members are cynical, and have a high degree of mistrust.
A weak sense of direction - the team needs to create common goals, take joint responsibility.
Insufficient commitment to performance - team needs accountability for the problem and the solution, based in performance measures.
Critical skills gaps - team needs to hire experts or develop skills.  They must be capable of admitting they need help - identify the type of help and go get it.
Getting unstuck:  - 1) revisit the basic of teams, 2) build on small successes, 3) inject new information and techniques, 4) get facilitation skills & training, 5) change team membership or leader

Transitions and endings will also effect the team, may drop them back into lower stages of Tuckman model of development - allow for that, don’t expect no emotion for losses. 
Categories: Blogs

Mean Time between Disruptions (MTD) a leadership Metric

Agile Complexification Inverter - Sun, 02/19/2017 - 05:09
A rant on Metric's I wish I had written...  so I'm going to just include it by reference and call it my own.

One thousand Words on Metrics

Here's a quote to get you even more interested in clicking that link...
ConclusionIn short, I find most grasping for metrics to be a reliable metric for lack of understanding of human behavior, not only that of those who would be measured but that of those who would do the measuring.If a higher-up wants a metric about a team, say, as an input to their judgment about whether the team’s work is satisfactory, oughtn’t there be some other way to tell?And if I choose nearly any metric on someone else’s behalf, doesn’t that reveal my assumption that I know something about how they do their good work better than they do?Or worse, that I prefer they nail the metric than do something as loose and floppy as “good work”? Well - will you look at that!  Yareev's even willing to apply his own metric to his work.  What a great example of a leader...
Let’s try that againNew metric (expiration = next subhead, privacy = public): I’m 0 for 1 on satisfying conclusions to this post.I’m hardly an expert on human behavior. If I were one, rather than being passive-aggressive and obstructive, I’d have a ready step to suggest to metrics-wanters, one that they’d likely find more desirable than metrics.Instead I have to talk myself down from passo-aggro-obstructo, by which time they’ve chosen what they’ll observe and the ready step I can offer is limited to encouraging them to observe the effects of their observation.Can you give me some better ideas?Here's my very special response to his request for comments.

   I'm wanting to +1 your whole rant, I'd like to nail it to the front doors, I'm thinking about a tattoo, but unsure where on my leader's body it should go...

   I have sometimes fantasied about asking the VP that want's a new metric, if it would be good for us to add one that measured their leadership of our group - I'll call this metric Mean Time between Disruptions (MTD).  MTD is calculated much like the old factory sign that said:
 "its been 1023 days since we killed someone at this factory, please be safe."   So let's start counting (I suggest in weeks) the time between a major disruption to the team.  For this basic metric we are looking at team formation dynamics (your familiar with Tuckman's Forming, Storming, Norming, Performing) and you Mr. VP desire the P word - but it comes after 3 stages of development beyond the F word).

   Let's start at the beginning and count weeks between Forming and ReForming.  You know like when you move a person on/off a team.  When you move the team's physical location, or when you give the team a new objective, then let's reset the clock.

   The metrics I've seen range from MTD = 0 to about 20 weeks for many teams I've worked with.  And Mr. VP says they desire persistent teams.

I would have put it on his site in the comments but I got a very dissatisfied error message from the system when I posted it... (wonder if he has a metric for failed comments?).

Agile in 3 Minutes  a podcast that discusses a journey toward agility (each episode in exactly 3 minutes).  I'm pondering... why does the magic number 3 come up in the Agile community so often?  Personally I feel it has to do with the Book of Armaments, chapter 2, verse 9 to 21; because 5 is right out!



See Also:
Team Metrics - Case Study
How could we measure Team Happiness?
Metrics for a Scrum Team  but don't confuse that post with Scrum Team Metrics which discusses the necessary and sufficient metric Velocity.
Do you really need a Project Management Office? (PMO effectiveness metrics)


Categories: Blogs

Synergic Reading Lessons

Agile Complexification Inverter - Sun, 02/19/2017 - 05:04


Wondering what other books I should read concurrently with the philosophy of this book, Other Minds, on the mind of our alien ancestors. In chapter one Peter is already mashing up Ismael and Darwin, so I feel it appropriate to do a bit of mix-in myself. I'm thinking Seven Brief Lessons on Physics will add spice. To bad I recycled How to build a Mind at Half Price Books.




I've also got to read Coaching Agile Teams by Lyssa Adkins for work's book club. And I may mix-in a bit of LEGO Serious Play, because I cannot get serious about coaching - seems like a play activity to me.




Maybe I will devise a quadrant model of these books. A Venn diagram of their overlapping topics.



Squid Communicate With a Secret, Skin-Powered Alphabet
Categories: Blogs

TrumpCare in its Infancy January 2017

Agile Complexification Inverter - Sun, 02/19/2017 - 05:03
I'm extremely concerned today for my country and this planet.  It appears that history is repeating.
    January 27th -- International Holocaust Remembrance Day.

President Trump bars refugees and citizens of Muslim nations entry into the U.S.A.

The New York Times
By Bundesarchiv, Bild 183-N0827-318 / CC-BY-SA 3.0, CC BY-SA 3.0 de
Four score and four years ago a dictator brought forth on the European continent an evolving plan to rule the world and subjugate the masses.

Now we are engaged in a great resistance, testing whether our nation, or any nations conceived from the learning of our mothers and fathers and so dedicated to liberty, can long endure.  We are met on a great social square of technologic creation.  We have come to dedicate a portion of our wealth, wisdom, and life to those in history that have offered their lives and wisdom so that we may learn and prosper.  It is altogether fitting and proper that we should do this.

But, in a larger sense, we can not dedicate -- we can not consecrate -- we can not hallow -- this square.  The brave women and men, living and dead, who struggle here, have consecrated it, far above our poor power to add or detract.  The world will little note, nor long remember what we say here, but it can never forget what they did here in the commons.  It is for us the living, rather, to be dedicated here to the unfinished work which they who fought here have thus far so nobly advanced.  It is rather for us to be here dedicated to the great task remaining before us -- that from these honored dead we take increased devotion to that cause for which they gave the last full measure of devotion -- that this nation, ruled by law, shall have a new birth of freedom -- and that government of the people, by the people, for the people, shall not perish from this planet.

-- David A. Koontz, human patriot


President Abraham Lincoln's address, on Thursday, November 19, 1863, to dedicate Soldiers' National Cemetery in Gettysburg, Pennsylvania, four and a half months after the Union armies defeated those of the Confederacy at the Battle of GettysburgFour score and seven years ago our fathers brought forth on this continent, a new nation, conceived in Liberty, and dedicated to the proposition that all men are created equal. Now we are engaged in a great civil war, testing whether that nation, or any nation so conceived and so dedicated, can long endure. We are met on a great battle-field of that war. We have come to dedicate a portion of that field, as a final resting place for those who here gave their lives that that nation might live. It is altogether fitting and proper that we should do this. But, in a larger sense, we can not dedicate—we can not consecrate—we can not hallow—this ground. The brave men, living and dead, who struggled here, have consecrated it, far above our poor power to add or detract. The world will little note, nor long remember what we say here, but it can never forget what they did here. It is for us the living, rather, to be dedicated here to the unfinished work which they who fought here have thus far so nobly advanced. It is rather for us to be here dedicated to the great task remaining before us—that from these honored dead we take increased devotion to that cause for which they gave the last full measure of devotion—that we here highly resolve that these dead shall not have died in vain—that this nation, under God, shall have a new birth of freedom—and that government of the people, by the people, for the people, shall not perish from the earth.

"Abraham Lincoln's carefully crafted address, secondary to other presentations that day, was one of the greatest and most influential statements of national purpose. In just over two minutes, Lincoln reiterated the principles of human equality espoused by the Declaration of Independence[6] and proclaimed the Civil War as a struggle for the preservation of the Union sundered by the secession crisis,[7] with "a new birth of freedom"[8] that would bring true equality to all of its citizens.[9] Lincoln also redefined the Civil War as a struggle not just for the Union, but also for the principle of human equality.[6]".

"Lincoln's address followed the oration by Edward Everett, who subsequently included a copy of the Gettysburg Address in his 1864 book about the event (Address of the Hon. Edward Everett At the Consecration of the National Cemetery At Gettysburg, 19th November 1863, with the Dedicatory Speech of President Lincoln, and the Other Exercises of the Occasion; Accompanied by An Account of the Origin of the Undertaking and of the Arrangement of the Cemetery Grounds, and by a Map of the Battle-field and a Plan of the Cemetery)."
 -- Wikipedia, Gettysburg Address
The books title is indictavite of the author's ability to thoroughly cover a topic. Everett's 2-hour oration had 13,607 words.



See Also:
     The Address by Ken Burns - PBS. Did you hear the story about the person that would give $20 bucks to grandkids that learned the Gettysburg Address? Encouraged me to learn it and it's history. History has an interesting emergent property... it appears to repeat, this is a emergent property from a complex system. It is the complex system practicing and learning... Humans as part of this universe's system, are so far (as we know) it's fastest learning sub-system. Our apparent loop duration is currently around Four Score years.Why President Obama Didn't Say 'Under God' While Reading the Gettysburg Address
Lincoln's 272 Words, A Model Of Brevity For Modern Times by Scott Simon

    Germany's Enabling Act of 1933. "The Enabling Act gave Hitler plenary powers. It followed on the heels of the Reichstag Fire Decree, which abolished most civil liberties and transferred state powers to the Reich government. The combined effect of the two laws was to transform Hitler's government into a de facto legal dictatorship."
     Women's March 2017 "A series of worldwide protests on January 21, 2017, in support of women's rights and related causes. The rallies were aimed at Donald Trump, immediately following his inauguration as President of the United States, largely due to his statements and positions which had been deemed as anti-women or otherwise reprehensible."
     Reichstag Fire Decree - Germany 1933  According to Rudolf Diels, Hitler was heard shouting through the fire "these sub-humans do not understand how the people stand at our side. In their mouse-holes, out of which they now want to come, of course they hear nothing of the cheering of the masses."[1].   Seizing on the burning of the Reichstag building as the supposed opening salvo in a communist uprising, the Nazis were able to throw millions of Germans into a convulsion of fear at the threat of Communist terror. The official account stated:  The burning of the Reichstag was intended to be the signal for a bloody uprising and civil war. Large-scale pillaging in Berlin was planned for as early as four o’clock in the morning on Tuesday. It has been determined that starting today throughout Germany acts of terrorism were to begin against prominent individuals, against private property, against the lives and safety of the peaceful population, and general civil war was to be unleashed…[2]
     TrumpCare: In the Beginning by Bill Frist - Nov. 2016, Forbes.  "Yesterday Americans woke up to news of a new president-elect: Donald J. Trump. The immediate question for those whose lives focus around lifting the health of individual Americans is, “What does this mean for health care in America?”
Categories: Blogs

Refactoring Towards Resilience: Async Workflow Options

Jimmy Bogard - Fri, 02/17/2017 - 23:44

Other posts in this series:

In the last post, we looked at coupling options in our 3rd-party resources we use as part of "button-click" place order, and whether or not we truly needed that coupling or not. As a reminder, coupling is neither good nor bad, it's the side-effects of coupling to the business we need to evaluate in terms of desirable and undesirable, based on tradeoffs. We concluded that in terms of what we needed to couple:

  • Stripe: minimize checkout fallout rate; process offline
  • Sendgrid: Send offline
  • RabbitMQ: Send offline

Basically, none of our actions we determined to need to happen right at button click. This doesn't hold true for every checkout page, but we can make that assumption for this example.

Sidenote - in the real-life version of this, we opted for Stripe - undo, SendGrid - ignore, RabbitMQ - ignore, with offline manual re-sending based on alerts.

With this in mind, we can design a process that manages the side effects of an order placement separate from placing the order itself. This is going to make our process more complicated, but distributed system tend to be more complicated if we decide we don't want to blissfully ignore failures.

Starting the worfklow

Now that we've decided we can process our three resources out-of-band, the next question becomes "how do I signal to that back-end processing to do its work?" This largely depends on what your backend includes, if you're on-prem or cloud etc etc. Azure for example offers a number of options for us for "async processing" including:

  • Azure WebJobs
  • Azure Service Bus
  • Azure Scheduler

In my situation, we weren't deploying to Azure so that wasn't an option for us. For on-prem, we can look at:

From these three, I'm inclined towards Hangfire as it's easy to integrate into my Web API/MVC/ASP.NET Core app. A single background job executing say, once a minute, can check for any pending messages and send them along:

RecurringJob.AddOrUpdate(() => {  
    using (var db = new CartContext()) {
        var unsent = db.OutboxMessages.ToList();
        foreach (var msg in unsent) {
            Bus.Send(msg);
            db.OutboxMessages.Delete(msg);
        }
        db.SaveChanges();
    }
}, "*/1 * * * *");

Not too complicated, and this will catch any unsent messages from our API that we tried to send after the DB transaction. Once a minute should be quick enough to catch unsent messages and still not have it seem like to the end user that they're missing emails.

Now that we've got a way to kick off our workflow, let's look at our workflow options themselves.

Workflow options

There's still some ordering I need to enforce on my external resource operations, as I don't want emails to be sent without payment success. Additionally, because of the resilience options we saw earlier, I don't really want to couple each operation together. Because of this, I really want to break my workflow in multiple steps:

In our case, we can look at three major workflows: Routing Slip, Saga, and Process Manager. The Process Manager pattern can further break down into more detailed patterns, from the Microservices book "Choreography" and "Orchestration", or as I detailed them a few years back, "Controller" and "Observer".

With these options in mind, let's look at each in turn to see if they would be appropriate to use for our workflow.

Routing Slip

Routing slip is an interesting pattern that allows each individual step in the process to be decoupled from the overall process flow. With a routing slip, our process would look like:

We start create a message that includes a routing slip, and include a mechanism to forward along:

Bus.Route(msg, new [] {"Stripe", "SendGrid", "RabbitMQ"}  

Where "RabbitMQ" is really just and endpoint at this point to publish a "OrderComplete" message.

From the business perspective, does this flow make sense? Going back to our coordination options for Stripe, under what conditions should we flow to the next step? Always? Only on successful payment? How do we handle failures?

The downside of the Routing Slip pattern is it's quite difficult to introduce logic to our workflow, handle failures, retries etc. We've used it in the past successfully, and I even built an extension to NServiceBus for it, but it tends to fall down in our scenario especially around Stripe where I might need to do an refund. Additionally, it's not entirely clear if we publish our "Order Complete" message when SendGrid is down. Right now, it doesn't look good.

Saga

In the saga pattern, we have a series of actions and compensations, the canonical example being a travel booking. I'm booking together a flight, car, and hotel, and only if I can book all 3 do I call my travel booking "complete":

//vasters.com/archive/Sagas.html

Does a Saga make sense in my case? From our coordination examination, we found that only the Stripe resource had a capability of "Undo". I can't "Undo" a SendGrid call, nor can I "Undo" a message published.

For this reason, a Saga doesn't make much sense. Additionally, I don't really need to couple my process together like this. Sagas are great when I have an overall business transaction that I need to decompose into smaller, compensate-friendly transactions. That's clearly not what I have here.

Process Manager - Orchestration/Controller

Our third option is a process manager that acts as a controller, orchestrating a process/workflow from a central point:

Now, this still doesn't make much sense because we're coupling together several of our operations, making an assumption that our actions need to be coordinated in the first place.

So perhaps let's take a step back at our process, and examine what actually needs to be coordinated with what!

Process Examination

So far we've looked at process patterns and tried to bolt them onto our steps. Let's flip that, and go back to our original flow. We said our process had 4 main parts:

  1. Save order
  2. Process payment
  3. Email customer
  4. Notify downstream

From a coupling perspective, we said that "Process Payment" must happen only after I save the order. We also said that "Email customer" must happen only if "Process Payment" was successful. Additionally, our "notify downstream" step must only happen if our order successfully processed payment.

Taking a step back, isn't the "email customer" a form of notifying downstream systems that the order was created? Can we just make an additional consumer of the OrderCreatedEvent be one that sends onwards? I think so!

But we still have the issue of payment failure, so our process manager can handle those cases as well. And since we've already made payments asynchronous, we need some way to signal to the help team that an order is in a failed payment state.

With that in mind, our process will be a little of both, orchestration AND choreography:

We treat the email as just another subscriber of our event, and our process manager now is only really concerned about completing the order.

In our final post, we'll look at implementing our process manager using NServiceBus.

Categories: Blogs

New Case Study: Kantar Retail sees major gains in Delivery, Finance, and Human Resources with SAFe

Agile Product Owner - Fri, 02/17/2017 - 16:46

“Our time to market is impressive for an enterprise solution. It’s a competitive advantage in the market that we can make major product changes every two months.”

Cédric Guyot, CEO, Virtual Reality at Kantar Retail

case-study-box-kantarHow do you deliver faster, retain top talent, and carve out a competitive advantage—all while spending less? For Kantar Retail Virtual Reality (KRVR), our latest case study, the answer was in deploying SAFe.

Working with clients such as Walmart, Target, and Unilever, KRVR’s virtual reality solutions enable realistic consumer research using virtual stores. When the company set out to develop a new VR solution in 2013, team members at the small company worried that a more formal approach could stifle ideas, but SAFe provided the framework the company needed while preserving creativity.

KRVR began their SAFe implementation with just six team members, and has now grown to 30, including all aspects of software delivery, QA, Scrum Teams, and UI/UX. They didn’t leave it at that. Today, they also have SAFe fully implemented on the Team and Program levels.

Practicing SAFe, KRVR brought the latest version of its product to market. Cloud-based Kantar Retail VR Infinity™ puts VR technology directly in the hands of users, and connects teams and customers to understand issues and opportunities quickly. What’s really valuable in this story is that Kantar Retail took the time to measure results across three spectrums: Delivery, Finance, and Human Resources. Their story is one of the better examples that highlights the across-the-board effect that SAFe can have on an enterprise. As you can see here, practicing SAFe made a big difference for Kantar Retail:

Delivery
• Delivery of major releases down from 6 to 2 months
• Time to market decreased from 9 to 3 months
• Reduced time to respond to client feedback from 3 months to 1 month
• Greater predictability, which enhances client satisfaction

Finance
• 27.5% decrease in cost per epic

Human Resources
• 41% to 28% decrease in the attrition rate
• 36%-43% increase in team productivity due to clear job responsibilities and processes
• Easier talent acquisition and retention due to openness and transparency

Given those metrics, top management is fully behind SAFe. SAFe not only elevates internal team satisfaction and hiring; the sales team now brings the company’s time to market into conversations with prospects.

“We’ve adopted an enterprise framework for agility, the SAFe framework. We’ve been more consistent. We’ve been able to articulate a roadmap to the business and to our clients and deliver in time and in full, which is a really positive milestone..”

Eric Radermacher, Product Manager, Virtual Reality at Kantar Retail

Check out the company’s full case study here.

Many thanks to those who helped share KRVR’s SAFe story: Cedric Guyot, CEO; Dmytro Vavriv, PhD, Delivery Manager; Paul Gregory, CTO; Dmytro Tsybulskyi, Release Train Engineer; Eric Radermacher, Product Manager; and Timofey Yevgrashyn, SPC and Agile coach.

Stay SAFe!
—Dean

Categories: Blogs

Why don’t monitoring tools monitor changes?

Xebia Blog - Fri, 02/17/2017 - 13:38
Changes in applications or IT infrastructure can lead to application downtime. This not only hits your revenue, it also has a negative impact on your reputation. Everybody in IT understands the importance of having the right monitoring solutions in place. From an infrastructure – to a business perspective, we rely on monitoring tools to get
Categories: Companies

Revisiting the Business Value of Agile Transformation, Part 1

BigVisible Solutions :: An Agile Company - Thu, 02/16/2017 - 18:00
Carrying the Business Case to the Rest of the Enterprise

Since “The Business Value of Agile Transformation” was first published five years ago, the fact that Agile generates far more business value than was previously possible using traditional methods has become generally recognized — at least in IT. However, it is still the case that the financial benefits that businesses actually obtain from their investment in Agile fall far short of what could be achieved.

One reason for this suboptimal performance is that, even as Agile speeds up software development in IT, upstream and downstream business activities remain mired in outdated business practices. If more business value is not delivered to the end-customer, more business value will not be received in exchange by the business. The solution is to apply Agile methods to eliminate bottlenecks that slow cycle time wherever they occur across the broader value stream. In some cases the worst bottlenecks are not in software development but upstream in product management or downstream in staging to production.

Unfortunately, if the scope of an Agile initiative is limited to a subset of the value stream, the opportunity to globally optimize the value stream is compromised. Although the business case for Agile is better understood in IT than ever before, it is still not well understood in other parts of the business (e.g., product marketing or portfolio management). Furthermore the jargon of IT frequently creates the impression in other parts of the business that they have nothing in common with IT. Consequently what might be accepted as a perfectly valid business case for IT may not seem applicable to others. This makes it all that more difficult to develop an agreement to collaboratively optimize the value stream between the IT and non-IT aspects of the business.

There is a straightforward solution to this dilemma. Lose the IT jargon and domain specific references and speak the lingua franca that is understood across the entire enterprise: money and risk. With this in mind, we will now revisit six business benefits expressed in financial and risk-reduction terms that are obtained through Agile methods and are available to all segments of the business.

  1. Reduced failed project risk
  2. Reduced over-budget and late projects
  3. Reduced waste
  4. Improved return through early and frequent releases
  5. Reduced write-off risk
  6. Higher-quality software with fewer defects

 

Benefit 1: Reduced Failed Project Risk

The purpose of project (alternatively: initiative, program, etc.) management is to reduce risk of failure (or if you are a glass-half-full kind of person, increase likelihood of success). Traditionally we begin with a charter that documents what should be delivered, when it should be delivered, and how much it should cost. The second step is to create a project plan that describes in detail the best approach for delivering the desired outcome that optimally balances cost and risk.

Project risk is managed first and foremost by avoiding deviation from the plan and getting quickly back on track when unplanned deviations occur. When, for whatever reason, a change to a specification or some other element of the plan is desired, a formal change process is used to make absolutely clear that the change is authorized and properly incorporated into the project plan. The change process is a tool that project managers use to control risk. Other risk controls include time and budget buffers added to increase the likelihood that the project will end as planned. There are many many controls designed to reduce different kinds of risks. Although controls reduce local risks, they increase project cost and complexity. Good project managers introduce the controls they need to achieve an acceptable level of risk and no more.

This classical approach to project management works extremely well when it’s very clear what the desired outcome and how to achieve it. For example, building a spec house from a blueprint using standard materials and experienced tradespeople. This approach to project management fits hand in glove with classical financial governance. Funds are approved if and only if a charter and plan exists that makes crystal clear how funds will be spent and the value of the delivered outcome.

However, what happens if you must begin construction without a clear idea of what it is that you are supposed to build and therefore you also are not sure what materials or skills you will need or when you will need them? How can you predict in advance how much it will cost or what it will be worth?

More and more this is the plight that every aspect of the business faces. Increasing business uncertainty means initiatives must begin without clear objectives or the knowledge needed to predict outcomes. Important characteristics of the solution cannot be known in advance and will only emerge as the project unfolds. Unexpected exigencies demand frequent, radical changes to project plans.

Traditional risk controls were designed to keep project plans from changing. Yet we now see that, for projects to succeed, plans must continually adapt to changing conditions. Adding more and more controls won’t reduce fundamental uncertainty, and the increased cost and complexity of additional controls means that, like the heads of the hydra, for every risk you control, new project risks pop up elsewhere in the project. Ironically enough, when conditions are uncertain, traditional risk management often leads to project failure rather than project success. And in today’s business environment when are conditions not uncertain?

No matter if you are in IT, product marketing or some other part of business, Agile mitigates failed project risk by:

  • Reducing risk under conditions of high uncertainty
    • Project Risk Strategy
      The Agile organization can implement a project risk strategy that recognizes that changes to project plans and specifications don’t always increase project risk and often reduce it.
    • Change as Constant
      The organization can reduce the cost of change by allowing, encouraging and anticipating modifications to the specs and plans throughout the project lifecycle.
  • Delivering incremental value
    • Even Failures Yield Value
      Incrementally delivering the outcome over the course of the project allows for value to be received even if the project is ended prematurely. It also allows outcomes to be tested in production to verify their value and improve subsequent efforts.
    • MMF
      By focusing on the minimal marketable feature (MMF), the Agile organization can to deliver something of value as early as possible
    • Highest-Value Features First
      The organization can also focus on delivering the highest-value features first.

Next up is how Agile reduces the incidence of projects delivered late and/or over-budget while also reducing waste.

Want to Skip to the Head of the Class?

Download the white paper that started it all. In “The Business Value of Agile Transformation”, SolutionsIQ CEO John Rudd discusses six business benefits that can be measured using traditional financial and production metrics and that are available to any Agile enterprise.

 

The post Revisiting the Business Value of Agile Transformation, Part 1 appeared first on SolutionsIQ.

Categories: Companies

It’s Not All Business – My YouTube Gaming Channel

Derick Bailey - new ThoughtStream - Thu, 02/16/2017 - 14:30

Most of what I post these days, is very directly related to the “business” of software development – either code, concepts or just flat out business stuff with WatchMeCode and other related ventures.

But I’m not all business, all the time.

IMG 0401

In fact, I keep a rather high level of play time in my life and being self-employed just makes that easier as I can do pretty much what I want, when I’m at home during the week.

Not the least of which is playing video games.

Last November, it occurred to me that I could record and stream my game playing to YouTube directly from my PS4.

Shortly after, I realized I could download the videos from YouTube, edit them, add voice-over, and upload them again.

Then I found this great little game recording device: the Elgato HD60 S, and it was Christmas… sooo…

All said and done, I’ve been uploading videos to a dedicated YouTube gaming channel for a couple of months now. I’m not doing one-a-day like a lot of the big names are, but I’m trying to do at least one a week. And I’m having a ton of fun doing it!

If you’re interested in gaming, at all, and want to see what I’ve been playing lately, check out the channel.

Code-Ninja Gaming

I’ve been playing and recording a lot of Battlefield 1, but have recently been adding in Titanfall 2 and I just started For Honor. There’s plenty of other games that I play and want to record, as well. And I’ve recently started live-streaming again (now that I have a basic setup that is working with the HD60S).

It’s all just a matter of making time to record and edit… which can be difficult when I spend days and nights working on products, marketing and sales pages, and doing everything I can to be productive.

But having a hobby is important. And I’m having fun with this one!

The post It’s Not All Business – My YouTube Gaming Channel appeared first on DerickBailey.com.

Categories: Blogs

Eating The Dog Food… In Public

Sonar - Thu, 02/16/2017 - 10:55

At SonarSource, we’ve always eaten our own dog food, but that hasn’t always been visible outside the company. I talked about how dogfooding works at SonarSource a couple years ago. Today, the process is much the same, but the visibility is quite different.

When I wrote about this in 2015, we used a private SonarQube server named “Dory” for dogfooding. Every project in the company was analyzed there, and it was Dory’s standards we were held to. Today, that’s still the case, but the server’s no longer private, and it’s no longer named “Dory”.

Today, we use next.sonarqube.com (nee Dory) for dogfooding, and it’s open to the public. That means you can follow along as, for instance, we run new rule implementations against our own code bases before releasing them to you. We also have a set of example projects we run new rules against before they even make it to Next, but seeing a potentially questionable issue raised against someone else’s code hits a different emotional note than seeing it raised against your own.

Of course, that’s the point of dogfooding: that we feel your pain. As an example, take the problem of new issues raised in the leak period on old code. Since we deploy new code analyzer snapshots on Next as often as daily, it means we’re always introducing new rules or improved implementations that find issues they didn’t find before. And that means that we’re always raising new issues on old code. Since we enforce the requirement to have a passing quality gate to release, this causes us the same problem you face when you do a “simple” code analyzer upgrade and suddenly see new issues on old code. Because we do feel that pain, SonarQube 6.3 includes changes to the algorithm that sets issue creation date so that issues from new rules that are raised on old code won’t be raised in the leak period.

Obviously, we’re not just testing rules on Next; we’re also testing changes to SonarQube itself. About once a day, a new version of SonarQube itself is deployed there. In fact, it happens so often, we added a notification block to our wallboard to keep up with it:

By running the latest milestone on our internal instance, each UI change is put through its paces pretty thoroughly. That’s because we all use Next, and no one in this crowd is meek or bashful.

Always running the latest milestone also means that if you decide to look over our shoulders at Next, you’ll get a sneak peek at where the next version is headed. Just don’t be surprised if details change from day to day. Because around here, change is the only constant.

Categories: Open Source

AgileEE Agile Eastern Europe, Kiev, Ukraine, April 7-8 2017

Scrum Expert - Thu, 02/16/2017 - 09:20
The AgileEE Agile Eastern Europe conference is a two-days event dedicated to promote Agile software development and Scrum project management in Ukraine and the Eastern European countries. It features Agile experts from all over the world, with well-known industry professionals from the US, Canada and Western Europe. In the agenda of the AgileEE Agile Eastern Europe conference you can find topics like “Test-Driven Development effectiveness – beyond anecdotal evidence”, “Focused Agile Coaching: co-create, capture and share your coaching vision”, “Achieving agility in strategy execution”, “Paint out the story point. Agile estimations and metrics in 90 minutes”, “Why do you scale: because you really need or because you don’t know how to organize without scaling?”, “Impact Mapping – creating software that matters”, “Retrospective Doctor: making Retrospectives better & more fun”, “Program/Portfolio Management in the Fields and the Tools to Organize It”, “Agile for Distributed and Remote Teams: Lessons Learned”, “Better planning with #NoEstimates”. Web site: http://agileee.org/ Location for the AgileEE Agile Eastern Europe conference: Ramada Hotel, 103, Stolichnoe Shosse, Kiev, Ukraine
Categories: Communities

AgileIndy, Indianapolis, May 12 2017

Scrum Expert - Thu, 02/16/2017 - 09:00
The AgileIndy Conference is a one-day event focuses on bringing Agile and Scrum thought leaders and practitioners from around the USA to Indianapolis for a great learning and networking experience. In the agenda of the AgileIndy conference you can find topics like “Agile Cross-Pollination: Growing Agile Adoption at Farm Credit Mid-America”, “Cultivating Agile Requirements”, “Secrets of Agile Estimation: Myths, Math, and Methods”, “Case Study: We Don’t Know Anything About Agile, but Let’s Give it a Try!”, “Framework-Driven Product Management”, “The Show Must Go On: Agile Leadership Lessons Learned from a Life in the Theatre”, “Coaching for Success – Practical Solutions for Building a High-Performance Organization”, “Emotional Intelligence for Agile Teams”. Web site: http://agileindy.org/conference/ Location for the AgileIndy conference: JW Marriott Downtown Indianapolis, 10 S West St, Indianapolis, Indiana 46204
Categories: Communities

Knowledge Sharing


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