Skip to content

Feed aggregator

Succeeding with Large Scale Agile

Scrum Expert - Wed, 03/01/2017 - 17:52
Learn how to succeed with large scale Agile. Implementing Agile in small, short lived projects is easy. The real challenge comes when the project becomes long-running, and it gets even harder when...

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

Empower - an action; not a command

Agile Complexification Inverter - Wed, 03/01/2017 - 16:01
You have not empowered a person by telling them "you are empowered."  This is a classic mistake in communication.  When one does this, they misinterpret their message, "I'm empowering you..." with the action that a verb such as empowerment requires to happen.  This person is taking a short cut, by giving the platitude of empowerment in place of any action that would be view by the other as empowering.

"When told that they are empowered to do something; this message is actually interrupted to dis-empower the persons agency."How does this misinterpretation occur?  Why do we humans mess up this simple act of communication?

Let's look at an example:

For a few months I had been working with a new team of software developers at a large organization.  Like many organizations they had already done the agile/scrum thing and it didn't work for them.  Recently the leadership had built a satellite office and started from a very small pool of tenured people to grow it's new "resource" of technical people.  This time the leadership decided that hiring some experienced people that had "done Agile" and "knew how to Scrum" might give them the needed energy to actually get somewhere with the initiative.  At least these experts could teach the new people how to do agile right.  I guess I was one of these "experts" (another term for a has-been drip under pressure).

Observing the new team for a few weeks I noticed they referred to their process by the label "kanban," yet they never appeared to move any sticky notes on their board, never made new ones or retired any old stickies.  Mostly they just pointed at them and talked about something not written on the note.  It was very difficult for the outsider (me) to follow the process they were using -- or maybe they were not using any process; and I was following them -- to nowhere.  This will take a bit more observation.

Although that was several months ago, and my memory is not the best at recovering details when there is no emotion overlaying the details, believe me there was little emotion at their stand up meetings, I'd call them boring (the meetings, not the people).  I don't remember in the 4 weeks I was observing that they ever shipped any software, never spoke about a customer visit, or discussing a solution with a customer - I don't think anything they talked about ever got done.

So, I some how convinced their manager that what they were calling a process, could not be named - and that wasn't a good thing (sorry Alexander that attribute is not the same as your "quality without a name" ).  It didn't reflect any known process.  He didn't know much about the process either.  It was labeled "kanban." Yet they didn't exhibit any of the behaviors of a team practicing the Kanban process, they didn't even know what steps the process might involve.  They had also tried scrum, but "it didn't work" either.  It was very difficult to discuss these failures with the team or the manager, they were reluctant to discuss what about the process had failed, nor what actions they implemented when these failures occurred.

I made a bold assumption - they didn't know anything about the processes they were espousing they were using.  They had been to training classes, therefore they knew ... something.  They could use the new lexicon in a sentence (90% of the time the sentences made sense).  But how do you tell someone they are ignorant (with the full meaning - that they no nothing about a subject and it's not their fault for having never been exposed properly to the knowledge).  That's a crucial conversation.  I rarely handle these well - I got lucky this time perhaps.  I suggested the team join me in a workshop to talk about the practices they are using and how these map to the Agile Manifesto.  We did this exercise and branched off into many valuable conversations.  During this exercise we decided they were already being Agile, so many of their practices supported the principles of the manifesto.  So the question was not if they were Agile, but how much was enough... could they improve their agility - did they want to try something different?  Along the way of this conversation we might have arrived at an understanding of a difference of opinion, when I used words in the lexicon I had intended to imply certain meanings that they did not intend when they used the words.  We often seemed to use similar phrases but rarely meant the same things actually happened.  That level of miscommunication can be tedious to overcome, while still keeping an open mind that the other person has something valuable to offer.

For example: they had been using the word "kanban" to describe the process they were using because that was the term applied to the Rational Team Concert (RTC) - template work flow the company created.  They had chosen that workflow because it was easier to use than the complicated scrum workflow the organization's PMO created.  Turns out it had nothing to do with the development process they were using.  They finally agreed that they were not doing Scrum, and didn't really know how to do it... they hadn't learned much from the powerpoint presentation (imagine that).

I got extremely lucky with one of the leaders of this team. She said to the team, that she thought the
team should give the scrum master (me) a chance, just go along with whatever I said, regardless of how stupid it sounded. Try it for a few weeks, it wouldn't hurt, and then in a few weeks decide if it was working for the team, or not.  I learned of this leader's suggestion to her teammates only months later.  It was without a doubt the turning point in the relationship.  After this détente, the team members began to implement with ease suggestions on how they could implement Scrum.  One might say that this leader empowered me, but never said a word about it to me.

We did more workshops in a scrumy fashion, we had a board of items to complete.  We tracked these items on a board right there in the workshop space.  Sometimes we split the topics up more.


Sometimes the topic didn't get finished in the time allotted and we had to decide if it was good enough to continue with other topics and come back later to finish the discovered aspects.  We used the rate at which we were progressing day after day to predict that we wouldn't get all of the topics covered by the end of the week.  But that was good enough, because each day the team selected the most important, most valuable topics and we put off the lease valuable.  Sometimes a topic was dependent upon another item on the board and we had to cover some of a less valuable item so that the dependency was resolved.  In these workshops we covered many Agile principles, the Scrum process framework (3 roles, 3 meetings, 3 artifacts, and a lot more), engineering  practices (many originally defined by Extreme Programming gurus), local organization customs, terms, policies, and procedures.  Much of what was suggested by some agile or scrum nutjob was in contradiction with the customs and policies of the organization - at least on the surface.  Great conversations were developed where the team joined into filling the shared pool of knowledge.  This pool of knowledge now with company and agile/scrum knowledge was easily sorted into new understanding of how both systems could co-exist and interrelate.  It wasn't easy but it generally worked.



The team started understanding the process of Scrum and working toward getting stories in the backlog to done.  Slicing stories that had proven too large in the past and delivering working software to the business each sprint.  They developed the ability to easily estimate a story or an epic set of stories within minutes.  Their ability to read their task board and predict which stories (if any) were not going to get completed within their sprint time-box that they quit wasting time tracking a sprint task burndown.  They understood that if they got into a new domain that ability might be diminished and they could easily revert to tracking task aspirin (a unit of effort; not time) on a chart in the future. The team knew their velocity and could accomplish a sprint planning session in about an hour.  They could predict when they needed to spend more time in refining tough stories before planning and they learned how to slice stories for value and leave the fluff on the cutting room floor.

But all was not well with a performing team...  (cue the scary music - set up a scene with dramatic lighting) ... the manager was looking for a way to measure the team.  And as people are wonting to do... without any thought they look for a dashboard to tell them how well the "team is being run."  They want to know if the "team is being driven at their top performance", and they need some numbers to prove it.  Generally this is a warning indication that many conversations were wasted and no learning occurred,  in hindsight the wrong person was doing too much of the talking and the other didn't draw from the pool of shared knowledge but instead just admired the pool from the shore, never bothering to enter.  The team's manager wanted me to build a dashboard tool using the company's tool of record (RTC) that would give him all the numbers that prove his team is performing well.

I've made a strategic decision over the years to not become the tooling expert - especially with the bountiful assortment of tools the software project management industry offers.  Needless to say I didn't want to become an expert in RTC (a tool rumored to be on it's way out for this organization that was in their 3rd Agile adoptions curve).  I asked what this dashboard would have on it, what it would display, etc.?  The answer fit on a sticky note, because that's what I had with me... something like velocity, the backlog, and what the team is currently working on was the manager's response.

Here's my Nth mistake.... I hoped the request would dissipate as many thing in a transition tend to do, so I wasn't motivated to create a dashboard for the manager that would reproduce the team's well maintained Scrum task board.  I offered to work with him in reading the board, he attended many of the team's Scrum sessions at the board, rarely engaged but appeared attentive.

[this story will continue ...  as I've lost my round-toit --  wonder if it's with my marbles?]

See Also:

The Rise of Emergent Organizations  by Beth Comstock

The ScrumMaster - How to develop a team - by Marcel van Hove

Categories: Blogs

Groundhog Day at the Agile Transition Initiative

Agile Complexification Inverter - Wed, 03/01/2017 - 12:53
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.


[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
[What Should You Do?]
Say you are in the office of VP of some such important silo, and they are introducing themselves to you (they are new at the Org.).  They ask you how it's going.  You reply, well, very well.  [That was the appropriate social response wasn't it?] Then they say, no - how's the agile transformation going?  BOOM!  That is a bit of a shocking first question in a get to know each other session - or is it that type of session - what should you do?

I will skip to the option I chose ...  because the other options are for crap - unless you have a different motive than I do... and that is a very real possibility, if so defiantly DON'T DO THIS:

Ask the VP if this is a safe space where you can tell the truth?  Be sincere and concerned - then listen.  There response is the direction you must now take, you have ceded control of your action to them, listen and listen to what is not said - decide if they want the truth or do they want to be placated.  Then give them what the desire.  For example (an obviously easy example - perhaps); imagine that the VP said:  I want the truth, you should always tell the truth.

Don't jump to fast to telling the truth... how can you ascertain how much of the truth they can handle?  You should defiantly have an image of Nicholson as Colonel Nathan R. Jessep as he addresses the Court on "Code Red".


You might ask about their style is it bold and blunt or soft and relationship focused.  You could study their DiSC profile to see what their nature may tell you about how to deliver the truth.

Imagine you determine that they want it blunt (I've found that given a choice must people say this, and only 75% are fibbing). So you suggest that it's not going well.  The transformation has come to an inflection point (pause to see if they understand that term).  You give some archeology - the organization has tried to do an agile transformation X times before.  VP is right with you, "and we wouldn't be trying again if those had succeeded."  Now that was a nice hors d'oeuvre, savory.  The main course is served - VP ask why?

Now you could offer you opinion, deliver some fun anecdote or two or 17, refer to some data, write a white paper, give them a Let Me Google That For You link. Or you could propose that they find the answer themselves.

Here's how that might go down:  Ask them to round up between 8.75 and 19.33 of the most open minded tenured (5 - 20 yrs) people up and down the hierarchy; testers, developers, delivery managers, directors, administrators (always include them - they are key to this process - cause they know every thing that has happened for the last 20 years).  Invite them to join the VP in a half day discovery task - to find out why this Agile thing get's ejected before it takes hold of our organization. If you come away from this workshop with anything other than - culture at the root of the issue, then congratulations your organization is unique.  Try the Journey Line technique with the group.  It's a respective of the organizations multi-year, multi-attempts to do ONE THING, multiple times.  Yes, kinda like Groundhog Day.

See Also:

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


Categories: Blogs

The Agile Fluency Game: Now Available!

James Shore - Wed, 03/01/2017 - 10:00
01 Mar 2017 James Shore/Blog

Five years ago, Arlo Belshee and I created a game about agile adoption. The ideas in that game influenced the Agile Fluency™ Model, Arlo's Agile Engineering Fluency map, and the Agile Fluency Diagnostic. We always intended to publish the game more widely, but the time and money required to do professional publishing job was just too much.

Until now.

I am very proud to announce that, in collaboration with the Agile Fluency Project, the game I've spent the last five years play-testing and revising is finally available! I'm conducting a special workshop with Diana Larsen that's packed full of useful exercises to improve your Agile coaching and training. Every participant will get a professional-produced box set of the game to take home.

Every time we've run the Agile Fluency Game, players have asked to get their own copy. Now it's finally available.

Sign up and learn more here.

Categories: Blogs

10 years of Agile @ Crisp. Next challenge: Global Warming!

Henrik Kniberg's blog - Wed, 03/01/2017 - 09:30

10 years ago, 2007, me and a few Crisp colleagues embarked on a mission: be best in Sweden at helping companies become agile. We had experienced first-hand the power of agile development, and wanted to use this newfound super-power to help both Crisp and our clients improve. Others joined us and – tadaa!  – Agile Crisplet was born (and the concept of crisplets)! That was the year I taught my first Certified ScrumMaster course together with Jeff Sutherland, co-creator of Scrum. Since then we’ve co-trained almost 30 courses! About 2-3 times per year. In fact, May 22-23 is our 10 year anniversary (join us at the course in Stockholm!).

Now 10 years has passed since our Agile Crisplet was formed, and I’m happy to see we have achieved more than we ever could have dreamed!

Dispensing with false humility here, we’ve somehow managed to become one of the world leaders in this field! Famous agile and lean experts partner with us. Super well-known product companies, large telecoms and banks, even government organizations, turn to us as first choice for agile guidance and training. Our videos and articles and books have racked up millions of hits, and we are basically overwhelmed with requests to do coaching, write book forewords, do conference talks and workshops, and run training courses. I’ve done almost 30 keynotes in 20+ countries. I’m amazed (and overwhelmed) every time I look at my inbox, I’ve had to hire an assistant just to turn down the 95% of all requests that we simply don’t have capacity to handle.

OK, so now what?

10 years is a long time, and now it’s time for a new focus! At least for me (Crisp is a no-CEO company where people are free to do whatever they want).

My personal mission has been “Help companies improve”, then it shifted to “Help the Good Guys Win”. I’ve been focusing on companies that have a good culture and build products that make the world a better place – companies like Spotify and LEGO. “Good Guys” in my book.

But I’ve gotten a little bit too comfortable in my role as “Agile Guru” (I don’t really like the term, but so many people call me that so I’ve decided to just accept it). My work started feeling repetitive, like I was doing things out of habit rather than out of passion. And at the same time, I was getting increasingly worried about global warming, especially after a climate change denier took the helm of one of the most powerful countries in the world.

And then it hit me. Shit! I’m solving the wrong problem! Here I am, feeling good about myself for helping cool, successful companies become even more cool and successful. And at the same time, the world is facing an unprecedented disaster, the sixth mass extinction event over the past 500 million years, caused by humans, and I’m doing nothing at all about it (in fact, making it worse by flying all over the place)! We like to take our existence for granted, but the dinosaurs ruled the earth for 160 million years (800 times longer than the human era so far!), and they were wiped in the last extinction event 65 million years ago. How can I look my children in the eyes, while we screw up the planet they are inheriting?

Over the years I’ve built up this wonderful arsenal of problem solving skills, so how about I use it to help solve the right problem instead? I started studying up on global warming, and realized that this really is the world’s biggest and most important problem, anything else seems tiny and insignificant in comparison. Kind of depressing, because what the heck can I do about it, I’m just one guy and a totally newbie on climate stuff.

But then I realized – wait! 10 years ago, I started off as a newbie (well… not an expert at least) on agile, and now my colleagues and I have managed to make a major world-wide impact on how companies work, helped them create more humane work environments, helped them succeed with their projects, helped them build awesome products and organizations. I’ve lost count of the number of people that have said “You changed my life” (for the positive… I think…)! What if we can pull off the same stunt again? A bit optimistic, yes, but worth a try!

We’ve developed a big arsenal of really useful skills – software development, system architecture, viral communication, teaching, facilitation, structured problem solving, community building, and more! AND we’re lucky enough to have some discretionary time and money – most of us don’t have to work full-time just to make a living. So let’s put it to use!

I started looking for solutions. The past two months I’ve been busy. Partnered with experts. Joined a solar energy startup and formed an electricity company. Formed a community – Climate Crisplet (half of Crisp, 20 people, joined almost immediately!). Studied up on CO2 emissions, started blogging about it. Found awesome tools like www.electricitymap.org. Invested in solar panels in Africa via Trine, an awesome startup that is trying to eliminate energy poverty (and reducing global warming as a side effect). Supported development of aviation biofuel. I’m basically exploring the solution space!

My biggest insight is that there is hope! The solutions are out there. Electric cars. Solar and wind energy. Mainly, we just have to stop burning oil and coal. And there is no reason for us to do so anymore, not for energy at least, and not from an economic standpoint either (even if we ignore climate impact, which is massive). A lot of very passionate smart people are at work saving the world. Lots of really cool stuff is happening! But it needs to happen faster, A LOT faster.

So that’s my new mission and focus: Help reduce global warming.

And that really translates to help find ways to reduce global CO2 emissions, which right now translates to help promote solar and wind energy and electric cars! And make oil & coal energy obsolete as fast as possible.

I’m definitely not an expert on this, so I’m trying to learn as much as I can. Exploring ways to make a difference, partnering with others who know more, spreading knowledge, and inspiring others to help out. People like Elon Musk, Bill Gates, and Al Gore are already making a huge difference, but the more people that pitch in the better.

My mantra is every ton counts, because one ton of CO2 is one ton, regardless of where in the world it is reduced. That’s my driving KPI.

Climate Crisplet is a starting point, so join if you are interested! I can’t promise strong leadership, just a gathering point for people that share this interest and are looking for ways to help out and inspire each other.

I have no idea where the journey will lead, but I’m enjoying it so far! After 10 years of being an “expert” it’s very refreshing to get to be a newbie again

Categories: Blogs

Scaled Agile Framework: 3.0, 4.0 and Beyond!

BigVisible Solutions :: An Agile Company - Wed, 03/01/2017 - 01:44

In January, Scaled Agile Framework (SAFe) 4.0 was officially released. This is a big deal in the industry but not everyone is clear on what to expect. Many of our readers don’t yet fully appreciate the scope of possibilities that Agile scaling frameworks like SAFe offer. We’d like to remedy this confusion with a two-pronged approach that focuses on informing our readers about what the Scaled Agile Framework (SAFe) is in general terms so that we can outline, again in general terms, what SAFe 4.0 offers.

What is the Scaled Agile Framework (SAFe)?

There are many resources on the web and even in dead-tree format describing what the Scaled Agile Framework is (i.e. “an online, freely revealed knowledge base of proven integrated success patterns for implementing Lean-Agile development at enterprise scale”), who invented it (Dean Leffingwell), etc. The only relevant information worth sharing here about SAFe in general concerns the business outcomes that SAFe can offer, namely*:

  • More engagement from employees
  • 20-50% increase in prod
  • 50% defect reduction
  • 30-75% faster time to market

*”The Real Deal with SAFe 4.0″ Agile Craft webinar with Dean Leffingwell.

SAFe’s major differentiator is its eagle-eye view of an Agile organization called the SAFe Big Picture along with supporting guidance toward its implementation. January’s release of version 4.0 contains a good deal of improvements to the last version, but in terms of the business value, this blog contains what you need to know.

Big Time Scaling

SAFe 3.0, in some ways, equated the portfolio level with the enterprise. 4.0 recognizes that the world’s frontrunners comprise many portfolios and even portfolios of portfolios. SAFe 4.0 now has a way of visualizing how portfolios interact and engage in an enterprise. Largely because of this distinction, the previous version of SAFe (3.0) is recommended for smaller enterprises (<100 people or less), while bigger corporations will be more interested in SAFe 4.0’s larger-scale capability.

Building in Quality

One of SAFe’s core values is Built-in Quality. 4.0 continues the framework’s evolution by embracing engineering techniques that address delivery obstacles at software, firmware and hardware levels. Software techniques include proven Extreme Programming practices like test-driven development, pair programming and refactoring, as well as collective code ownership.

Focusing on Solution intent of very large sets solutions where the implementation of each solution is in context to the targeted environment/customer, etc.

Calling out the SAFe principle #3 – Manage Variability, Preserve Options by leveraging Set Based design concepts that arrive at better design decisions

Guidance for external suppliers of the overall solution – be it Hardware, Firmware, or Software

Embracing Kanban systems at all levels in SAFe

Guidance for Direct and indirect Customers around validation, participation, and budgeting
 

Implementing SAFe 4.0 with SPC Certification | Upcoming Opportunities

If your organization is using SAFe and you are interested in becoming SPC4 certified, we invite you to attend one of our upcoming public SAFe classes. These highly experiential classes provide the perfect place for you to learn what it takes to train others in SAFe practices and principles, while also giving you an opportunity to share ideas with other Agile and SAFe practitioners and to learn from some of our most seasoned Consultants. The class is designed for middle management, directors, executives, especially at the Program and Project level.

View Upcoming Courses

The post Scaled Agile Framework: 3.0, 4.0 and Beyond! appeared first on SolutionsIQ.

Categories: Companies

How to introduce Agile to non-IT teams

TargetProcess - Edge of Chaos Blog - Wed, 03/01/2017 - 00:00

It’s clear that the Agile Methodology is not restricted to software development teams. Countless organizations have improved their flexibility and delivery speed with an Agile mindset, and many have successfully scaled Agile through every department. Agile is already widely used in marketing, education, and even auto manufacturing.

If you’re a non-IT team that wants to adopt the Agile mindset, you will likely encounter some resistance to change. This is good. Criticism of Agile can help your application of its values to improve.  To encourage non-IT teams to embrace Agile, you should first demonstrate the value that an Agile mindset can deliver. 

Don’t prescribe; encourage

The Agile methodology has (unfortunately) been fairly well-saturated with buzzwords and prescriptive practices. As Dipanjan Munshi puts it, “The process whose manifesto declared ‘People over Processes’ has now became a standardized prescriptive process in itself.”

To avoid putting anyone off unduly, don’t introduce Agile as a set of prescriptive processes. Instead, frame it as a cultural practice and a mindset for approaching work. Note that a successful Agile culture will help to increase employee independence, trust, and personal responsibility. In a traditional environment, management ends up being responsible for both failures and successes. In an Agile environment, responsible individuals shoulder this responsibility.  

It’s important for Agile transformations to happen more-or-less organically. Nobody wants to put up with another vague strategy change that’s been mandated by management. This is the the sort of thing that an Agile mindset is supposed to eliminate.

Don't transform; iterate

There are a lot of practices that have formed around Agile; introduce them iteratively, and you’ll be able to the avoid the culture-shock that has stagnated many transformationsTo get started, research Scrum and Kanban. Try to understand which practices might work for you, and why:

Kanban - Kanban uses a board with cards that represent work items. As a work item progresses from idea to completion, it is moved forward through the board's swimlanes. It's great for helping teams adjust to frequently changing priorities. Setting WIP (work in progress) limits helps teams to reduce context switching and avoid getting bogged down by an ever-expanding scope of work.

Scrum - Scrum is great for organizing teams and for making continuous improvements to your work process using Retrospectives. It's fairly heavy on planning (compared to Kanban), and uses fixed iterations to help teams understand and improve their velocity. Most teams utilize a Scrum Master - an individual whose job it is to facilitate meetings, remove impediments, and generally help the team get their work done.

If you're aiming for a large scale shift to Agile, take extra care when planning change. Peter Merel, a long-time Agile consultant and founder of the XSCALE Alliance, advocates the use of steel-thread squads: A small number of progressive people adopt Agile practices and measure their metrics to prove the productivity benefits. The team then divides like a cell and spreads to other teams. This allows for a natural change that doesn’t disrupt the established organization. The transformation is iterative rather than sudden; Agile is adopted using Agile.  

Bridge the gaps between software development and the domain of your teams

Some Agile coaches have noted that it is difficult to link the idea of “delivering working software” to other fields of work. Opposition tends to come in the form of rebuttals such as “We’re too quality-focused to adopt this practice.”  This line of thinking comes from a lack of understanding about the core principles of Agile.  Keep in mind that Agile does not mean sacrificing quality for speed. Rather, it means you should deliver the highest quality you can, without getting bogged down by process or bureaucracy.

The concept of developing “Working software” can easily translate to any field. It simply means the first point where you can deliver real value to your customers. Define the variables of what "working software" and "end user" means to your team. Figure out what what could be considered as one of the basic building blocks of your final deliverable so that you can get feedback at an early stage. 

You also shouldn't feel obligated to use the vernacular of Agile. It was created in an IT world, and might be irrelevant or confusing for your teams. Consider changing the terminology of your tool or process to reflect the vernacular your team already feels comfortable with. For example, a marketing team might rename Features as Campaigns, a sales team might rename User Stories as Leads, etc.  

Synchronize, but don’t get bogged down by ceremony

When you have multiple teams practicing Agile, you run the risk of creating what has come to be called "Agile silos." These are teams which are practicing Agile internally, but lack cross-team or cross-departmental coordination. This is not a good recipe. There needs to be some sort of unifying vision to help turn these different teams into a collaborative ecosystem. There are multiple frameworks to help you plan this out, including SAFe, DaDLeSS, and LeadingAgile

So, it's important to synchronize your teams, but you also have to be careful to not get bogged by ceremony and bureaucracy. A central pillar of Agile is replacing processes with interactions. Adopting the ceremonies of Agile without understanding their purpose is a huge red flag. Don't constrain your teams by trying to over-synchronize them with processes that they don't need. 

“Humans are of very low value as cogs in a machine doing identical things in interchangeable ways. That's for robots. Humans are most valuable when they have high autonomy, and able to play to their unique strengths and histories, particular sensitivities, op-tempos, and patterns of privileged information. The idea of "wisdom of the crowds" in fact rests on humans having diverse, unique private knowledge bases. The madness of crowds kicks in with synchronization and imitation.”  -Premature Synchronization is the Root of All Evil

Final thoughts

One of the biggest pitfalls you can fall into is looking at Agile as a cure-all panacea that will help you do more work in less time. This is not what Agile is about. It's about breaking out of the rigid structures that constrain individuals from completing their work in the best possible way. 

Dilbert on Agile

Learn the various techniques and strategies that Agilists have accumulated over the years, and pick the mixture that works best for you. Above all, don't lose sight of the values in the original Agile Manifesto.

Categories: Companies

Check out February 2017 Scaled Agile Insider

Agile Product Owner - Tue, 02/28/2017 - 20:28

insider_blog_fanThe February 2017 edition of the Scaled Agile Insider is hot off the press. This almost-monthly email is the best resource for getting all the latest news from the SAFe universe in one place. In this edition you’ll find:

  • SAFe Summit Registration now open
  • Microsoft publishes guidance for mapping SAFe to Visual Studio TFS Agile Tools
  • Does SAFe apply to small teams?
  • The critical role of the SPC
  • Video: Lean-Agile transformation at SimCorp with IJI
  • Case Study: 60% faster time to market for Kantar Retail: provider of VR technology to Walmart and Target
  • Upcoming SAFe webinars and presentations from Scaled Agile thought leaders

The Insider is intended to provide you with the wider range of information—including things like commercial aspects, case studies, and third party opinions—that will help you do your job and get the most out of SAFe. To that end, you’ll find a broad range of topics and resources, including: links to new downloads, ‘must-read’ articles, books, videos, the lastest case studies, webinar announcements, classes and event news, and more.

If you’ve attended a SAFe class, you are likely already subscribed. If not, go here to subscribe and read the latest editions.

As we work to improve its value to the community, we’d love your thoughts. Are we covering what’s important to you? Should we provide less or more? Turn it into an online publication? All ideas are welcome.

Stay SAFe!
—Dean

Categories: Blogs

Certified ScrumMaster Training Workshop in Ottawa—May 1-2

Notes from a Tool User - Mark Levison - Tue, 02/28/2017 - 19:47
Agile Pain Relief presents a two-day Certified ScrumMaster Workshop in Ottawa—May 1-2 taught by certified ScrumMaster Trainer Mark Levison.
Categories: Blogs

Agile Amped Greatest Hits from the Inaugural Business Agility Conference

BigVisible Solutions :: An Agile Company - Tue, 02/28/2017 - 18:00

Last week, SolutionsIQ participated in the inaugural Business Agility Conference in an effort to unite the many and varied organizations tasked with expanding Agile practices and values throughout the enterprise around a cohesive definition of Business Agility as well as approaches to achieving it. Our Agile Amped podcast series was onsite to keep the inspiring conversations going and to bring them to our readers and our followers.

Being the first ever event of its kind, Business Agility 2017 was an eye-opening, invigorating conference where professionals from all of the many departments that compose an enterprise organization, including business, IT, marketing, HR, recruiting, sales, etc. as well as the many Agile thought leaders, coaches, trainers and consultants championing the collective change to an Agile mindset. Top of mind for everyone in attendance was pinning down Business Agility, and in each of our podcasts we asked our interviewees how they defined the concept and how they would work to bring it into their individual enterprises. In his white paper “The Third Wave of Agile”, SolutionsIQ Chairman Charlie Rudd defines the two waves of Agile that have brought us to where we are now: riding the third wave of Agile, Business Agility — being able to deliver rapid value that thrills users as well as to disrupt existing markets and create new ones that solve problems that users may not even recognize yet. These are the capabilities that our Enterprise Innovation Solution aim to give organizations who have already established a rapid, responsive product delivery capability.

Bjarte Bognes Takes Us “Beyond Budgeting”

One of our favorite podcasts featured Bjarte Bogsnes author of “Implementing Beyond Budgeting – Unlocking the Performance Potential” and chairman of the Beyond Budgeting Institute. Besides discussing the history and envisioned future of the Beyond Budgeting movement, Bjarte also chats with us about something he calls management innovation. He says that, despite the fears of leadership to innovate their organization’s approach to management, “You can get great competitive advantage with [management] innovation as with product and technology innovation. And competitive advantage — that is a language that they understand.”

Business Agility is the Future of Agile

One of the most exciting things about attending and participating in Business Agility 2017 is seeing how much Agile is affecting every part of the organization. Attendees were passionate about how they were leveraging Agile approaches and thinking to problems that have plagued business, operations and support for decades — a problem that the increasing complexity in today’s day and age demands more innovative solutions. Here are some of the innovative solutions that some of our favorite Agile Amped interviewees had to share:

And these are just a portion of the amazing podcasts we were able to capture in New York City. There are 15 new podcasts from last week’s event waiting for you to jump into, whether you’re inside or on the go! And just in case you haven’t already…

The post Agile Amped Greatest Hits from the Inaugural Business Agility Conference appeared first on SolutionsIQ.

Categories: Companies

Neo4j: Graphing the ‘My name is…I work’ Twitter meme

Mark Needham - Tue, 02/28/2017 - 17:50

Over the last few days I’ve been watching the chain of ‘My name is…’ tweets kicked off by DHH with interest. As I understand it, the idea is to show that coding interview riddles/hard tasks on a whiteboard are ridiculous.

Hello, my name is David. I would fail to write bubble sort on a whiteboard. I look code up on the internet all the time. I don't do riddles.

— DHH (@dhh) February 21, 2017

Other people quoted that tweet and added their own piece and yesterday Eduardo Hernacki suggested that traversing this chain of tweets seemed tailor made for Neo4j.

@eduardohki is someone traversing all this stuff? #Neo4j

— Eduardo Hernacki (@eduardohki) February 28, 2017

Michael was quickly on the scene and created a Cypher query which calls the Twitter API and creates a Neo4j graph from the resulting JSON response. The only tricky bit is creating a ‘bearer token’ but Jason Kotchoff has a helpful gist showing how to generate one from your Twitter consumer key and consumer secret.

Now that we’re got our bearer token let’s create a parameter to store it. Type the following in the Neo4j browser:

:param bearer: ''

Now we’re ready to query the Twitter API. We’ll start with the search API and find all tweets which contain the text ‘”my name” “I work”‘. That will return a JSON response containing lots of tweets. We’ll then create a node for each tweet it returns, a node for the user who posted the tweet, a node for the tweet it quotes, and relationships to glue them all together.

We’re going to use the apoc.load.jsonParams procedure from the APOC library to help us import the data. If you want to follow along you can use a Neo4j sandbox instance which comes with APOC installed. For your local Neo4j installation, grab the APOC jar and put it into your plugins folder before restarting Neo4j.

This is the query in full:

WITH 'https://api.twitter.com/1.1/search/tweets.json?count=100&result_type=recent&lang=en&q=' as url, {bearer} as bearer

CALL apoc.load.jsonParams(url + "%22my%20name%22%20is%22%20%22I%20work%22",{Authorization:"Bearer "+bearer},null) yield value

UNWIND value.statuses as status
WITH status, status.user as u, status.entities as e
WHERE status.quoted_status_id is not null

// create a node for the original tweet
MERGE (t:Tweet {id:status.id}) 
ON CREATE SET t.text=status.text,t.created_at=status.created_at,t.retweet_count=status.retweet_count, t.favorite_count=status.favorite_count

// create a node for the author + a POSTED relationship from the author to the tweet
MERGE (p:User {name:u.screen_name})
MERGE (p)-[:POSTED]->(t)

// create a MENTIONED relationship from the tweet to any users mentioned in the tweet
FOREACH (m IN e.user_mentions | MERGE (mu:User {name:m.screen_name}) MERGE (t)-[:MENTIONED]->(mu))

// create a node for the quoted tweet and create a QUOTED relationship from the original tweet to the quoted one
MERGE (q:Tweet {id:status.quoted_status_id})
MERGE (t)–[:QUOTED]->(q)

// repeat the above steps for the quoted tweet
WITH t as t0, status.quoted_status as status WHERE status is not null
WITH t0, status, status.user as u, status.entities as e

MERGE (t:Tweet {id:status.id}) 
ON CREATE SET t.text=status.text,t.created_at=status.created_at,t.retweet_count=status.retweet_count, t.favorite_count=status.favorite_count

MERGE (t0)-[:QUOTED]->(t)

MERGE (p:User {name:u.screen_name})
MERGE (p)-[:POSTED]->(t)

FOREACH (m IN e.user_mentions | MERGE (mu:User {name:m.screen_name}) MERGE (t)-[:MENTIONED]->(mu))

MERGE (q:Tweet {id:status.quoted_status_id})
MERGE (t)–[:QUOTED]->(q);

The resulting graph looks like this:

MATCH p=()-[r:QUOTED]->() RETURN p LIMIT 25

Graph  21

A more interesting query would be to find the path from DHH to Eduardo which we can find with the following query:

match path = (dhh:Tweet {id: 834146806594433025})<-[:QUOTED*]-(eduardo:Tweet{id: 836400531983724545})
UNWIND NODES(path) AS tweet
MATCH (tweet)<-[:POSTED]->(user)
RETURN tweet, user

This query:

  • starts from DHH’s tweet
  • traverses all QUOTED relationships until it finds Eduardo’s tweet
  • collects all those tweets and then finds the author
  • returns the tweet and the author

And this is the output:

Graph  20

I ran a couple of other queries against the Twitter API to hydrate some nodes that we hadn’t set all the properties on – you can see all the queries on this gist.

For the next couple of days I also have a sandbox running https://10-0-1-157-32898.neo4jsandbox.com/browser/. You can login using the credentials readonly/twitter.

If you have any questions/suggestions let me know in the comments, @markhneedham on twitter, or email the Neo4j DevRel team – devrel@neo4j.com.

The post Neo4j: Graphing the ‘My name is…I work’ Twitter meme appeared first on Mark Needham.

Categories: Blogs

100 days

Growing Agile - Tue, 02/28/2017 - 11:36
I stumbled onto this video last week. It’s about a lady who taught herself to dance in 100 days. It’s amazing! The “Dance In A Year” Video Becomes A Platform For Anyone To Learn A Skill In 100 Days It made me really wonder what is possible if you just dedicate yourself for 100 days – that’s […]
Categories: Companies

Agile Trends, Sao Paolo, Brazil, April 12-13 2017

Scrum Expert - Tue, 02/28/2017 - 10:00
Agile Trends is a two-day conference focused on Agile software development and Scrum project management that takes place in Sao Paolo in Brazil. All the talks are in Portuguese. In the agenda of the...

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

Agile Games, Cambridge, USA, April 3-5 2017

Scrum Expert - Tue, 02/28/2017 - 09:00
The Agile Games Conference is three-day annual event organized by Agile New England that focuses teaching, demonstrating, and improving Agile and organizational effectiveness using game theory. In...

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

Random Thoughts on Business Models and Cost of Delay

Powers of Two - Rob Myers - Tue, 02/28/2017 - 02:50
I cover Cost of Delay and CD3 (Cost of Delay Divided by Duration) in my Essential Agile Product Leadership course. (CD3 being similar to WSJF). This part of the course is derived from from the work of Joshua J. Arnold, with Mike Cohn's business modeling "dimensions" (may be my term) as a starting point in the thinking process.

Mike Cohn's business modeling stuff is somewhat software-oriented, so it may be a good place to start for Agile (or Agile-hopeful) organizations.
I think I may have divided Mike Cohn's business modeling stuff into "dimensions" so that I could better explain them, but I'm no longer certain who did what.  I also added a little to it. It's safe to say this is strongly based on the work of Mike Cohn.
PurposeThe dimension of Purpose is the selection of why we are building what we are building:
  • New: New customers, new markets, improved cash flow.
  • Upsell: Upgrades and enhancements for existing customers.
  • Retention: Avoids losing customers or cash flow.
  • Efficiency: Saves money while enhancing growth.
  • Reputation: Improves our standing in the market, e.g., feature-parity, repairing defects. (I may have added this one...)
NecessityThe dimension of Necessity is a rough model of how we see this feature improving value:
  • Mandatory: A Minimal Marketable Feature (MMF).
  • Linear: Adds nominal value to the MMFs.
  • Exciter: Will create enthusiasm and joy in the user community.
ProcessLastly, the dimension of Process, which may have been added by me as a catch-all for remaining things from Mike's set, or so I could add topics that I think folks should consider when exploring their Cost-of-Delay and Duration estimates:
  • Cycle Time: Time it takes between receiving a request and delivery (or use) of the feature.
  • Waste: Things we do that may not provide value. E.g. re-work due to defects.
  • Risk: Things we may or may not be doing that will result in a loss of value.
  • Operational expenses: Keeping the lights on, and many others.
  • Cost of Delay: What it obviously costs to wait, i.e. lost opportunity. (See below.)
  • Complexity: Keeping it smartly simple.
Cost of Delay
The dimensions give leaders some starting points to think about as they come up with their cost-of-delay estimates, and helps them identify other folks to talk to--and what to ask them--in order to uncover other time and hidden cost estimates. "CD3 is cross-functional!" I say. At least as cross-functional as the best DevOps-embracing Scrum team.
I strongly emphasize that:
  1. All estimates must be provided by the people doing that part of the work, and that know the most about that estimate based on prior experience.
  2. Estimates must come with the mutual trust and understanding that an estimate is neither commitment nor guarantee, but is being used to choose between high-level options.
  3. CD3 is a starting point for ranking features, but that leaders cannot just sit back and let the equations do the release planning for them.
  4. If these techniques are not being done at the highest levels (e.g., portfolio planning), then they're going to be pointless at the feature level.
And I sometimes quip that, since value is an estimate, and time is an estimate, that the "estimate" units cancel out. ;-) 
Categories: Blogs

Refactoring Towards Resilience: Process Manager Solution

Jimmy Bogard - Mon, 02/27/2017 - 23:30

Other posts in this series:

In the last post, we examined all of our coordination options as well as our process coupling to design a solution for our order processor. In my experience, it's this part of design async workflows that's by far the hardest. The code behind building these workflows is quite simple, but getting to that code takes asking tough questions and getting real answers from the business about how they want to handle the coupling and coordination options. There's no right or wrong in the answers, just tradeoffs.

To implement our process manager that will handle coordination/choreography with the external services, I'm going with NServiceBus. My biggest reason to do so is that NServiceBus, instead of being a heavyweight broker, acts as an implementor of most of the patterns listed in the Enterprise Integration Patterns catalog, and for nearly all my business cases I don't want to implement those patterns myself. As a refresher, our final design picture looks like:

We've already gone over the API/Task generation side, the final part is to build the process manager, the Stripe payment gateway, and event handlers (including SendGrid).

In terms of project structure, I still include Stripe as part of my overall order "service" boundary, so I have no qualms including it in the same solution as my process manager. With that in mind, let's look first at our order process manager, implemented as an NServiceBus saga.

Initial Order Submit

From the last post, we saw that the button click on the UI would create an order, but defer to backend processing for actual payments. Our process manager responds to the front-end command to start the order processing:

public async Task Handle(ProcessOrderCommand message,  
    IMessageHandlerContext context) {
    var order = await _db.Orders.FindAsync(message.OrderId);

    await context.Send(new ProcessPaymentCommand
    {
        OrderId = order.Id,
        Amount = order.Total
    });
}

When we receive the command to process the order, we send a command to our Stripe processor from our Saga, defined as:

public class OrderAcceptanceSaga : Saga<OrderAcceptanceData>,  
    IAmStartedByMessages<ProcessOrderCommand>,
    IHandleMessages<ProcessPaymentResult>
{
    private readonly OrdersContext _db;

    public OrderAcceptanceSaga(OrdersContext db)
    {
        _db = db;
    }
    protected override void ConfigureHowToFindSaga(
        SagaPropertyMapper<OrderAcceptanceData> mapper)
    {
        mapper.ConfigureMapping<ProcessOrderCommand>(m => m.OrderId);
    }

It doesn't seem like much in our process, we just turn around and send a command to Stripe, but that means that our front end has successfully recorded the order. With our initial command sent, let's check out our Stripe side.

Stripe processing

On the Stripe side, we said that payments are an Order service concern, which means I'm happy letting payments be a command. Between services, I prefer events, and internal to a service, commands are fine (events are fine too, I just prefer to coordinate/orchestrate inside a service).

We can implement a fairly straightforward Stripe handler, using a Stripe API NuGet package to help with the communication side:

public async Task Handle(ProcessPaymentCommand message,  
    IMessageHandlerContext context)
{
    var order = await _db.Orders.FindAsync(message.OrderId);

    var myCharge = new StripeChargeCreateOptions
    {
        Amount = Convert.ToInt32(order.Total * 100),
        Currency = "usd",
        Description = message.OrderId.ToString(),
        SourceCard = new SourceCard
        {
            /* get securely from order */
            Number = "4242424242424242",
            ExpirationYear = "2022",
            ExpirationMonth = "10",
        },
    };

    var requestOptions = new StripeRequestOptions
    {
        IdempotencyKey = message.OrderId.ToString()
    };

    var chargeService = new StripeChargeService();

    try
    {
        await chargeService.CreateAsync(myCharge, requestOptions);

        await context.Reply(new ProcessPaymentResult {Success = true});
    }
    catch (StripeException)
    {
        await context.Reply(new ProcessPaymentResult {Success = false});
    }
}

Most of this is fairly standard Stripe pieces, but the most important part is that when we call the Stripe API, we track success/failure and return a result appropriately. Additionally, we pass in the idempotency key based on the order ID so that if something goes completely wonky here and our message retries, we don't charge the customer twice.

We could get quite a bit more complicated here, looking at retries and the like but this is good enough for now and at least fulfills our goal of not accidentally charging the customer twice, or charging them and losing that information.

Handling the Stripe response

Back in our Saga, we need to handle the response from Stripe and perform any downstream actions. Now since we have this issue of the order successfully getting received but payment failing, we need to track that. I've handled this just by including a simple flag on the order and publishing a separate message:

public async Task Handle(ProcessPaymentResult message,  
    IMessageHandlerContext context)
{
    var order = await _db.Orders.FindAsync(Data.OrderId);

    if (message.Success)
    {
        order.PaymentSucceeded = true;

        await context.Publish(new OrderAcceptedEvent
        {
            OrderId = Data.OrderId,
            CustomerName = order.CustomerName,
            CustomerEmail = order.CustomerEmail
        });
    }
    else
    {
        order.PaymentSucceeded = false;

        await context.Publish(new OrderPaymentFailedEvent
        {
            OrderId = Data.OrderId
        });
    }

    await _db.SaveChangesAsync();

    MarkAsComplete();
}

Depending on the success or failure of the payment, I mark the order as payment succeeded and publish out a requisite event. Not that complicated, but this decoupling of the process from Stripe itself means that when I notify downstream systems, I'm only doing so after successfully processing the Stripe call (but not that the Stripe call itself was successful).

SendGrid event subscriber

Finally, our publishing of the OrderAcceptedEvent means we can build a subscriber to then send out the email to the customer that their order was successfully processed. Again, I'll use a NuGet package for the SendGrid API to do so:

public class OrderAcceptedHandler  
    : IHandleMessages<OrderAcceptedEvent>
{
    public Task Handle(OrderAcceptedEvent message, 
        IMessageHandlerContext context)
    {
        var apiKey = Environment.GetEnvironmentVariable("MY_RAD_SENDGRID_KEY");
        var client = new SendGridClient(apiKey);
        var msg = new SendGridMessage();

        msg.SetFrom(new EmailAddress("no-reply@my-awesome-store.com", "No Reply"));
        msg.AddTo(new EmailAddress(message.CustomerEmail, message.CustomerName));
        msg.SetTemplateId("0123abcd-fedc-abcd-9876-0123456789ab");
        msg.AddSubstitution("-name-", message.CustomerName);
        msg.AddSubstitution("-order-id-", message.OrderId.ToString());

        return client.SendEmailAsync(msg);
    }
}

Again, not too much excitement here, I'm just sending an email. The interesting part is the email sending is now temporally decoupled from my ordering process. In fact, email notifications are just another subscriber so we can easily imagine this sort of communication living not in the ordering service but perhaps a CRM service instead.

Wrapping it up

Our process we designed so far is pretty simple, just decoupling a few external processes from a button click. With an NServiceBus Saga in place to act as a process manager, our possibilities for more complex logic around the order acceptance process grow. We can retry payments, do more complicated order acceptance checks like fraud detection or address verification.

Regardless, we've addressed our initial problems in the distributed disaster we created earlier. It took quite a few more lines of code and more moving pieces, but that's always been my experience. Resilience is a feature, and one that has to be carefully considered and designed.

Categories: Blogs

We’ve moved from UserVoice to Service Desk for Idea Management

TargetProcess - Edge of Chaos Blog - Mon, 02/27/2017 - 18:13

Our new Service Desk application can be used to manage almost any kind of Request. One of its most common use cases is Idea Management, which allows you to gather feedback and prioritize features in your product based on your customers’ needs.

For the past several years, we’ve been using UserVoice for Idea Management. Now that our own Service Desk provides the same functionality and more, it’s time to move on. Last week we carefully moved about 10,000 users and 2,800 ideas to https://helpdesk.targetprocess.com to make sure your feedback is not lost.

This means that the forum at https://tp3.uservoice.com is now deprecated. You are welcome to share your ideas at https://helpdesk.targetprocess.com.

migration_complete
The other thing we want to highlight is that you can also use the Service Desk + Targetprocess combo to collect and manage ideas for your own projects. Service Desk has all the usual features such as voting and comments, it allows you to easily link ideas to particular work items in Targetprocess, and it’s free. Also, as our own Product Owner observed, it's much more convenient to manage incoming ideas when you have all the power of Targetprocess to back you up.

Service Desk can be enabled from the Settings page in Targetprocess. Take a look at our guide if you need help getting started, or send us a message at support@targetprocess.com.

Tip: You can create Custom Request Types to expand your use of the Service Desk for almost any kind of application. If you’re not using Service Desk for customer support, just remove the Issue and Question request types and rename them to something that corresponds to your needs.

 

In addition to all that, we have just released a widget that can be handy if you have your own system and don’t need the full Service Desk application, or if you just want users to submit requests without leaving your website.

widget_plan

We understand that you might need some flexibility from the default settings, so we made the widget customizable. You can hide elements like top requests, description, and attachments, define default request types and privacy, and change the form's subject text. It is already available for you and you can embed it anywhere – all you need to do is to provide a link to your Service Desk with the correspondent parameters. See our guide for more information.

Categories: Companies

The Costs of Non-Delivery and Non-Conformance

Scrum Expert - Mon, 02/27/2017 - 17:16
Like the notion of technical debt, the concept of management debt relates to the leadership issues that prevent a successful Agile transformation. This article from Agile transformation expert Sriram...

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

Article 7 in SAFe Implementation Roadmap series: Prepare for ART Launch

Agile Product Owner - Mon, 02/27/2017 - 16:52
Click to enlarge.Click to enlarge.

There are twelve ‘critical moves’ in the SAFe Implementation Roadmap, and seven of them are all about reaching the tipping point, then training, preparing, and planning.

Prepare for ART Launch is the last move in that ‘plan and prepare’ group, guiding you through the final steps needed before actually launching your train. From a change-management perspective, the first ART is very important with potentially far-reaching implications. It sets in motion the first material change to the way of working and will generate the initial short-term wins that help the enterprise build momentum.

This article covers the key activities involved in preparing for an ART launch. They include:

  • Define the ART
  • Set the launch date and cadence calendar
  • Train the ART leaders and stakeholders
  • Establish the Agile teams
  • Train Product Managers and Product Owners
  • Train the Scrum Masters
  • Assess and evolve launch readiness
  • Prepare the program backlog

You’ll also find some invaluable tools, such as:

  • Agile Release Train canvas, which helps teams identify the principal ART roles (Thanks Mark Richards!).
  • Agile team roster template, which helps bring clarity and visibility to the configuration of each team
  • ART readiness checklist, helps you prepare to ensure a successful launch

There’s a lot to be accomplished at this stage, and it is important work, but as you’re going through this stage keep in mind that SAFe is based on the empirical Plan-Do-Check-Adjust (PDCA) model. There is no such thing as perfect readiness for a launch, and it’s not even recommended as the experience of the first PI will inform future activities.  As Confucius said, “Better a diamond with a flaw than a pebble without.”

Read the full article here.

As always, we welcome your thoughts so if you’d like to provide some feedback on this new series of articles, you’re invited to leave your comments here.

Stay SAFe!
—Dean and the Framework team

Categories: Blogs

Knowledge Sharing


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