Coaching the Frozen Middle to be Agile

Scope:

This is an article which presents some quick fire ideas for agile coaching the “Frozen Middle”.

Problem:

The “Frozen Middle” is a term used for middle-management who do not wish to become Agile. They want to avoid this situation at all costs. This is because unless there are incentives, there is nothing in it for them except massive risk. That is their perception anyway.

It becomes a problem as it is middle management who really support and lead real cultural change within an organisation. We need them to be Agile or an Agile transformation will fail.

Some approaches for dealing with the problem of the “Frozen Middle” look at work around process or removal techniques [1]. But this does not deal with the systemic existence of that mindset. The change for the change agents has not really happened.

The problem therefore remains under the surface and is often the reason why a lot of Agile Transformations fail to evolve. They are moderately successful but then hit a ceiling and freeze with no thaw.

Solution:

The solution is one of culture change [2]. To create a new cultural mindset within middle-management. One technique or approach is not enough. There is not a one size fits all. If only!

As with so, many coaching situations it depends upon the details of the situation. This can become frustrating as there is no clear answer, but we can look at some options that together may help us progress a cultural change. Which ones are useful then?

Before coaching can commence though, we actually need to train people in the basics of Agile and also Lean techniques. Often leaders are great at leadership, but have not had exposure to the fundamentals of a topic. Thus they do not know it. However rather than express this as sometimes people can feel this is a weakness, they avoid it. Becoming in denial. They need a starter point as they are Shu [3].

This could take the form of training upon Agile Fundamentals [4] and also the Cost of Delay [5]. Fundamentals explains what Agile is to them and Cost of Delay is nice starter of why they need it. Then we can move onto the "Coaching" and look for Ha and "Mentoring" for the Ri.

ShuHaRi [4]

After which we can provide:

• Coaching on immediate Goals.
• Coaching on organisational structure.
• Coaching on adding Business value.
• Coach them to learn all by themselves.
• And many other topics as they arise [5].
  We need to be curious when coaching them.

One major caveat that should be in place beforehand is that there must already be an Agile Transformation vision being endorsed and championed by the senior leadership. If Agile has to bubble up, it will fail as it is not seen as addressing the wishes of executive. You always need to "feed the machine".

The end result is that we can help middle management change themselves faster 

through coaching and thus treat them with respect by following the…….

Agile Link:

Agile Manifesto where it states:

“Individuals and interactions over processes and tools” [6]

Processes and tools can help but as they are Individuals too, this is why we need through interactions Coach the Frozen Middle to be Agile.

This is also evident on my Agile Poster as Value of Respect [7].

References:

[1] Agile Makes Organisations Work: http://www.agileconference.org/wp-content/uploads/2013/10/Michael-Short-Agile-Make-Organisations-Work-Leadership-Makes-Agile-Work.pdf

[2] Galvanize the “Frozen Middle”: http://lithespeed.com/lean-pmo-galvanize-middle/

[3] ShuHaRi: http://martinfowler.com/bliki/ShuHaRi.html

[4] Agile Fundamentals training: https://icagile.com/icagile-certified-professional

[5] Cost of Delay topic: https://en.wikipedia.org/wiki/Cost_of_delay

[6] ShuHaRi image: https://www.scrumalliance.org/community/articles/2011/may/scrum-from-student-to-master

[7] Advice for Agile Coaches: http://www.prettyagile.com/2013/10/advice-for-agile-coaches-on-dealing.html

[8] Agile Manifesto:

http://www.agilemanifesto.org/

[9] Agile Poster:
https://agiledogma.blogspot.co.uk/2014/04/agile-development-poster-there-are.html

Implementing an Agile Follow-The-Sun Model

Scope:

This article looks at the problems of Implementing an Agile Follow-The-Sun Model.

Problem:

The world these days seems as if everyone is on-line, constantly connected. Therefore there is no downtime any more for Products that wish to survive in a 24/5.5 working week.

These products must be built, enhanced and maintained. As we know from experience Waterfall cannot solve this problem, only Agile can. This has been documented in many places [1] and [2].

However it is not that simple:

• How can a follow the sun model work for Agile teams spread across the globe?
• What happens when we come to demo/psi to the Product owner across global teams review meetings?
• How do we perform global retros?
• How do we refine the product backlog? 

Solution:

What is required are multiple teams that work upon the same product. With this advocated as the solution it is not surprising that scaling frameworks have come to the fore.

Many hands make light work. [3]

The point they miss is that modern Agile teams are now global. The flow does not stop when one teams Iteration/Sprint Ends. The Product flow must be handed to the next team to continue the Value Stream/Chain [4].

Follow The Sun - Value Stream

As we can see from the above diagram a team in Singapore will have had their daily team meeting/scrum and at the end of the day will have another scrum meeting to hand over to the London team.

The objective of this handover should be hopefully to hand over as little as possible. Thus giving a clear run to the next team. A relay race if you will, where the baton is handed over cleanly. London then hands over to San Fran, San Fran to Singapore and so on at the end of the day.

For the events that an Agile team has to perform nothing changes. They still perform the same activities at the same time, however they will need multiple Product Owners, multiple Team Leads/Scrum Masters.  These many will have to co-ordinate (tel/video-conferences) together to make it work. To make this scale there will either have to be a Product Manager as in SAFe [5] or one of the PO’s will wear a dual hat as a the Lead PO.

A single accountable person is always needed to make the final decision. They should of course be totally empowered and available to make that decision. No silent and disengaged stake holders.

The same goes for the Team leads and if possible get the teams together. Sometimes fly them out during quite times, video conferences for the teams. Bring them together during industry events. There are many activities that can be done.[6]

Flowing Global Agile Delivery is possible but not easy as the teams must evolve to act as One Team.

Agile Link:

This is also represented on my Poster, whereby the background image is of 3 different types of people (teams) and has the words One Team to represent this. [7]

References:

[1] Benefits to Follow the Sun: http://www.agileengineeringdesign.com/2008/06/are-there-real-benefits-to-follow-the-sun-and-remote-working-models/

[2] Adopting Agile Methods for Follow-the Sun: https://translate.google.co.uk/translate?sl=auto&tl=en&js=y&prev=_t&hl=en&ie=UTF-8&u=https%3A%2F%2Fulir.ul.ie%2Fbitstream%2Fhandle%2F10344%2F3461%2FKroll_2013_adopting.pdf%3Fsequence%3D2&edit-text=

[3] Phrase Definition: http://www.dictionary.com/browse/many-hands-make-light-work

[4] Value Stream/Chain: https://en.wikipedia.org/wiki/Value_chain
[5] Product Management - SAFe: http://www.scaledagileframework.com/product--and-solution-management/

[6] Distributed Agile: http://agileindia.org/uploads/downloads/IntroductionToDistributedAgileDevelopment.pdf

[7] Agile Poster: https://agiledogma.blogspot.co.uk/2014/04/agile-development-poster-there-are.html

Coaching Lean Teams on Scrum

Scope:

This article looks at how one could coach Lean teams on Scrum.

Problem:

Sometimes I get the great opportunity to Coach teams that are not software development teams. Such as a Lean team working within the Business, tasked with finding Waste [1].

One such occasion where my organization had a cultural Agile transformation going on, I was able to do just that. When I first started talking to the Lean team, I pointed out to them that historically Scrum and Agile borrow heavily from Lean. As a result they asked me to come in and present Scrum to them.

So, how does one coach a Lean team on Scrum?

Solution:

Well I went back to the basics, presenting all the activities, events, principles, values, and more of Scrum. But this was merely consulting via a presentation. It is not coaching.

One of the techniques that a Coach uses is to ask questions so, that the client team finds their own answers by themselves. People are more likely to accept these findings if they discover them on their own. Rather than ones that are force-fed to them. As they have made these discoveries through their own experiences. This is one of the many differences of Coaching compared to Consultation.

To enable the Lean team in this, after the presentation I facilitated a “game” with them. Whereby I provided them with a familiar Lean diagram of PDCA [2].

PDCA [3]

I then asked them as part of the game to place the Scrum activities, events, artifacts and anything else they thought relevant from Scrum on the picture to see where they thought it matched.

By observing the teams conversations, I could see the debates going back and forth. I made no effort to interfere. I let them get on with it, whereby the team made its own discoveries.

Anyway here is what this particular team came up with:

As long as the team were not too far off, for me it didn't really matter what they came up with. The point was to get them to learn, understand and converse as a team on Scrum. How it maybe useful for them and learn this all by themselves. Becoming a self-organizing team.

Agile Link:

I presented Scrum to the team, then coached them using a Lean approach they were familiar with (PDCA), asking them to map Scrum to it. The game enabled them to think and learn about Scrum. A successful outcome was obtained as the team went away with the idea of implementing Scrum.

For me my personal learning was the power of Coaching over Consulting.

That is, while there is value in the items on the right, we value the items on the left more. [5]

Scrum of course is on my Agile Poster [6]

References:

[1] Lean Wastes: http://leanmanufacturingtools.org/77/the-seven-wastes-7-mudas/

[2] PDCA: https://en.wikipedia.org/wiki/PDCA

[3] PDCA Image: https://commons.wikimedia.org/wiki/File:PDCA_Process.png

[4] Ri: http://martinfowler.com/bliki/ShuHaRi.html

[5] Agile Manifesto: http://agilemanifesto.org/

[6] Agile Poster:

https://agiledogma.blogspot.co.uk/2014/04/agile-development-poster-there-are.html

Agile Vendor Management

Scope:
Sometimes it makes sense to outsource a delivery or augment an existing Agile delivery using a people externally to your company from a Vendor. This article talks about how to still be Agile once the people come on board for your delivery.

Problem:

While there are many great articles on the net about how to engage a Vendor to supply people, few discuss what happens how to manage when the Vendor is on board. The often talk about how to get them in not how it works once the engagement is authorised.

Examples Include:

• Agile Vendor Management [1]
• Agile can’t be adapted to manage/control vendors. [2]
• Create a Vendor Contract While Keeping Agile [3]
• Making agile work for clients and vendors [4]
• Managing Client and Vendor Expectations [5]

While these are fantastic articles, one you have them in? What do you do?

The the real problem with Vendor Management is the same for all teams whether they are internal or external. How do you keep them Agile on the delivery?

We need an Agile approach for Vendor management set-up. But what does that mean? Let us look at the tangibles.

As most organisation often do, when creating a new team, to ensure that it remains Agile we can use proven prescribed methods such as Scrum to help us here. Scrum Theory as advocated within the Scrum guide has:

“Three pillars uphold every implementation of empirical process control transparency, inspection, and adaptation” [6]

Scrum Pillars [7]

Team Augmentation Set-Up:

For augmentation when using Vendor product as an enabler for the overall end product, it is wise to have at least one member of the delivery team from the Vendor. This means that Vendor enabler for delivery can be set-up, integrated and supported by the Vendor itself with visibility of transparency to the team, from within the team as it delivers. It also allows the team to inspect and adapt to the underlying product as knowledge is transferred from Vendor to the rest of the team.

Examples of this could be a racing team that uses a different underlying engine from a Vendor manufacturer. Having the Vendors expertise on site will greatly help the racing team integrate the engine correctly and fine tune it overall as the racing car is raced again and again. Similarly for a micro-services team leveraging a Vendors ESB product. Having a Vendors expertise working with the team to set-up, integrate and maintain the product allows transparency and the opportunity for the team to inspect and adapt with the underlying technology.

The augmented member of the team must become one with team and the team one with them.

External Team Set-Up:

In the situation when the team is supplied by a Vendor, things get more complicated naturally with more external people. Thus a different approach to leveraging Scrum is required.

When looking to on-board a team, co-location is paramount. However how does one gain transparency to the team if co-location is challenging? Including the technical delivery level, when the team is not part of the organisation? Here the reverse of augmentation can be applied. Whereby an internal employee joins the team, preferably as the Team Lead/Scrum Master.

If you cannot supply a trained, experienced Scrum Master then it is better to have Vendor face off. Whereby one Vendor supplies the Scrum Master and the other supplies the team. The Scrum Master then should be able to provide the transparency into the teams Agile capability at all times. Their job will be to servant lead the other Vendor team. Make it clear that they will never be able to supply their own team so, they must work together to make it work. This should stop the risk of mini-waterfall happening under the covers.

Most Vendors do not like this as they often over the long term want to keep all their failings hidden, having their own lead allows them to arbitrage the Client when they need too. Do not let them get away with it. If they won't comply then do not give them the Business. It's that simple.

Next, if you can possibly do this, is to interview everyone who is in the team. Often Vendors will hoodwink the Clint by supplying one or two top people as loss leaders and the rest are so, junior they might as well be off the street. Why would you want to hire a mediocre team? Make sure the team is stocked with senior people in the expertise that is required. Creating an Elite team is the only way to provide a delivery on time, to budget and to quality. If you cannot do this, then once again get another Vendor to interview them. Bring the expertise in, but in the right way.

Once again most Vendors will be aghast at this. Often stating that:

“we supply a managed service, we do not allow body shopping”

Actually this is how Vendors recruit themselves, one person at a time. They hardly ever recruit whole teams. Remind them of this, because if its good enough for them. It is should be acceptable and good enough for their Clients. 

As a side note when recruiting software engineers/developers it has been my experience that rather than asking for Agile ones, asking for people that are experienced in TDD is more beneficial for the delivery. Agile methods seem to be quicker to teach than TDD. Thus I find TDD experts learn Agile faster, than the other way around. Focus on this first for skills in recruiting developers if you can.

TDD Source [8]

The other excuse is:

“How can we ever develop our people if the more junior people are never allows to work with the customer?”

Their miss-management of their Business, should not be your problem. If they want to develop junior staff, then you may be willing to risk allowing them in the team your paying for if they are supplied for free. If not, then that is their problem. It is not up to you to manage their Business. You have your own to worry about. Do not let them place sub-standard people within the delivery team your paying for. If this costs extra, then it is worth it to avoid the risk of failure.

The Product Owner must be from your Business. This role cannot be outsourced. It is too critical. From the principles of the Agile Manifesto:

“Business people and developers must work together daily throughout the project.” [9]

Which leaves us to apply the some standard Agile/Scrum framework techniques:

• Single PBI system to track all work. This avoids arbitrage of priorities.
• Independent Scrum Master supporting the team, whilst also being loyal to the Client.
• Team is empowered to get on with the delivery and is not hit by any politics of Vendor vs Client.
• Agreed Ready state (not Scrum, but you can use a DoR) that evolves as the team makes discoveries. Avoiding Garbage In.
• Agreed DoD that evolves as the team makes discoveries. Avoiding Garbage Out.
• Review Event has two inputs, a demo for sign off in an independent environment and potentially shippable product.
• As the Product is delivered, then document the delivery. Preferably in the company Wiki and knowledge transfer everything. How everything is enabled, set-up, maintained. Everything to do with the Product and around the Product.
• Provide collaboration tools, chat, tele/video conferencing not just email or issue trackers. Work as a team. This allows Inspect and Adapt, with Transparency.

Scrum States of Ready and Done source [10]

Charging Model:

Fixed Price never works, unless you know the Future. Either the Client gets a deal and the Vendor sacrifices Quality to make a profit or the Vendor gets a deal and the Client over pays. There is no in between and anyone who has done it successfully has gotten lucky. Luck is not a professional way to run a Business, it is gambling.

Time and Materials gives you a complete breakdown transparency of costs as you go along. With fixed team sizes in Scrum one see costs upfront for 3-6 months in advance. Here the Client has the lead and the Vendor gets paid for the work they actually deliver, not what everyone guesses they may deliver or not!

It also allows you to see a breakdown of the costs per person and allows you to hire by each team member as eluded to above. As long as the Scrum Master and Product Owner are internally your people, then they can also prevent the risk of the Backlog growing forever with perceived never ending work.

Here both sides win as the details of the delivery are not constrained by the contract but by collaboration. As the Agile Manifesto states:

“Customer collaboration over contract negotiation” [11]

Client leadership, by renewing when needed or off-boarding the team after any 2-week Sprint.

Off-boarding:

Very few Agile articles talk about this. Even with long-lived teams at some point either you will provide your own team members or the delivery is done, done. At this point the Vendor has to go. If you have followed the approach above, with Time and Materials, independent Scrum Master, Business Product Owner, full transparency, documented Product whereby the artifacts are all owned in-house. Then it is as simple as just ending the Business contract.

This is why the above approach is optimal for delivery, as it mitigates the risk and puts most of the power back in the Clients hands without crippling the delivery team.

Do we have to use Scrum?

No we do not. Kanban for example is quite affective for flow based deliveries. However Kanban can quickly turn into “throw it over the wall” for immature teams, then quality is lost and it becomes an Agile cargo cult.

Thus a prescribed approach at the start with a Vendor lets everyone know where they stand. Scrum is also well known and understood. Re-use what we know works.

Agile Link:

The link is to leverage Scrum, to utilise a Time and Materials approach whereby the Roles and Responsibilities are defined up front without sacrificing the capability of the team being Agile. This is why Scrum is a part of my Agile poster [12].

While Elite teams often move towards a more flow based Kanban approach over time, some of us have to deal with Vendors. In this case Scrum comes ready made Out Of The Box. If we are careful we can have the best of both worlds.

References:

[1] Agile Vendor Management: https://blogs.msdn.microsoft.com/nickmalik/2004/10/16/agile-vendor-management-removing-waterfall-from-outsourced-projects/

[2] Agile can’t be adapted to manage/control vendors: http://agencyagile.com/agile-for-agencies-myth-14-agile-cant-be-adapted-to-managecontrol-vendors/

[3] Create a Vendor Contract While Keeping Agile: https://www.techwell.com/2013/05/create-vendor-contract-while-keeping-agile

[4] Making agile work for clients and vendors: https://austin2014.drupal.org/session/consultancy-scrum-making-agile-work-clients-and-vendors.html

[5] Managing Client and Vendor Expectations: http://www.agilealliance.org/wp-content/uploads/files/session_pdfs/Managing%20client%20and%20vendor%20expectations%20in%20an%20agile%20project.pdf

[6]: Scrum Guide: http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-US.pdf#zoom=100

[7] Scrum Pillars Image: http://www.slideshare.net/vineetpatni31/scrum-a-short-guided-tour

[8] TDD Image: http://blog.cellenza.com/alm/visual-studio/tutorial-test-driven-development-with-visual-studio-2012/

[9] Agile Manifesto Principles: http://agilemanifesto.org/principles.html

[10] Scrum States of Ready and Done image: http://www.innolution.com/blog/definition-of-ready

[11] Agile Manifesto: http://agilemanifesto.org/

[12] Agile Poster:
https://agiledogma.blogspot.co.uk/2014/04/agile-development-poster-there-are.html

Agile UX Is a Misnomer

Scope:

The UX community seems to struggle with Agile. They seem to want a special approach called Agile UX to resolve this struggle. As this quote states:

"Agile UX describes update of Agile Software Methodology with UX Design methods." [1]

I am not sure how such a wild statement of being able to 'update' Agile can be true and this article will show that there is no such thing. Agile UX is a misnomer.

User Experience

Problem:

From the many articles on the web UX professionals seem to be historically Waterfall people in their mindset. Which is why they struggle with Agile.

A classic example of this is whereby the UX practitioner works outside the team performing research (analysis) and design outside of the teams inspect and adapt feedback loop.

"UX Must Work at Least One Step Ahead of the Sprint" [2]

Not within the Sprint as part of the Agile team. Also retrospectives with the team seem not to be practiced within the UX community. This is akin more to mini-waterfall than Agile.

UX creates Mini-Waterfall [11]

Others in the UX community want to 'game' Agile because it does not fit their work practice.

"For example, how can you test information architecture without all content areas in place?" [3]

In the above scenario presented, rather than use mock-ups or deliver separately parts of the feature value content, all must be built before anything can be tested. Thus rather than deliver customer value, the goal is changed (gamed) to that which suits the UX person rather than the customer/user. And so, it continues:

"sprint 1 might be a paper mockup of the entire minimal viable product. Sprint 2 might be a high fidelity wireframe and sprint 3 the final build." [3]

So, we are back to phased delivery and Waterfall again rather than producing features the customer can use and get value from after the first Sprint. 

It can get worse than this. Whereby UX experts even take iteration commitment away from the delivery teams. Often trotting out excuses such as not enough UX people as within this article [4]. Yet as can you see from the article, somehow once they are away from the rest of the Agile team they manage to resolve this issue still with the same number of people.

"large planning sessions with all POs present is because it lets us set priorities as a group" [4]

Surprisingly the comment above is only for the UX and PO's backlogs and not the team. They are not planning with the Agile teams. So, once they are done, someone will still have to place it back on the real-backlog for the Agile team to re-prioritise for delivery. Unless of course they are forced to take it on which is even worse. The comments on that page speak volumes as well about separation from the Agile team.

On many of the well known UX websites there is article after article on this subject. The solution it seems is to have an additional specialism to UX called Agile UX. This way UX skilled professionals can fit the Agile approach into their experiences and skills. Hence the constant stream of statements of working around Agile.

The role has even appears in SAFe as a specialist role in itself. Yet other roles that are in the Agile Team within SAFe do not get this special treatment [5].

A more comprehensive study alludes to the problems UX professionals have with Agile. Let us look at this article and the problems UX people 'think' they have with Agile [6].

"The opinion that ‘This is good enough.’ Design implementation always goes to the bottom of the priority for the sake of MVP… Pushed to the next release and stay in the UX bug list forever." [6]

Of course this is not the UX designers call and it is up to the Product Owner. But the UX professional does not see it this way. Their design is somehow more important than the MVP!

"No time is considered for design of the overall framework. Scrum teams jump into feature releases. They’re building inside out instead of outside in or holistically." [6]

Teams can build architecture holistically, therefore they can do this with UX too. You have to convince them like you would any stake-holder. Join the team.

"Design needs to align earlier and sooner with the business owners to ideate and come up with a great design." [6]

Indeed it does just like any design delivery that any Agile team has to work upon. Being outside the team causes this problem.

"Developers build whatever UI they think is appropriate while a designer is working on design iteration or testing." [6]

This happens when the UX person is not part of the team. People will work separately if they are working in silo's.

“developer-centric culture” [6]

Agreed and is just as bad as a UX-centric culture. Avoid both as neither are Agile.

Then these three final quotes are all the same:

• Sometimes engineers are thinking of the solution without understanding the need.
• The challenge is that supporting two teams that are both on nearly identical timelines
• Difficulty in being aligned with the engineering team which is mostly in India. [6]

The above are not UX specific problems. Even if this were a back-end messaging system, these would still be problems. UX is nothing to do with the above. Yet cited as UX specific problems with Agile by the article.

When we get to the real route cause it is this.

Once you state that your skill-set must have an Agile diversification to it, you saying it is a technical specialism in itself.

Agile is a method and approach in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development, early delivery, continuous improvement, and encourages rapid and flexible response to change.

For example a Java Developer codes in Java. If they are Agile they do not code in Agile Java as there is no such specialism. They are still a Java Developer but one that also is Agile. Thus a UX Designer does not become an Agile UX Designer as there is no specialism as Agile UX.

Agile UX is therefore a Misnomer.

Solution:

Rather than professionals add UX Agile into their work, the solution is that they be Agile. As the old Agile saying goes:

"Don't do Agile, be Agile" [7]

If you just 'do' Agile, this means you sometimes do it and other times you do not as opposed to 'be'ing Agile in your approach to all of your work regardless of skill set. Either you be Agile or you be not. There is no partial credit for half-Done in Agile.

Once UX professionals be Agile, they should also be a part of the team. As important as any other member of the team and just as special. But not separate from the team. They should be in the team as a fully fledged full time dedicated team member. You cannot be in the team if you are also part of another team or area. No part-timers.

Indeed as one person added a comment to the article that sums it up better than I ever could:

"We have had our UX resources embedded in the scrum teams for the past 4 years. They are as much accountable for forward development work as a java developer or a DBA or a BA or a test engineer. UX related tasks are are added to user stories accordingly, we don’t have separate stories for UX. IMO, keeping UX away from normal development sprints is risky and probably not agile. Same with technical documentation, a story isn’t “done” if it still needs UX work (or documentation work) at the end of a sprint. Seek to minimize hand-offs and the pain points will ease." [6]

Tangible solutions of this exist and from within the UX Community itself. This article despite the title has a community solution [8] when scaling and here as part of the team [9].

Indeed in SAFE 4.0 maybe Dean should consider removing the specialism on his Big Picture. As SAFe 4.0 itself when you dig into the detail he has conceded that the UX person must be a part of the team. Which is the way it should be. As can be seen here in this SAFe 4.0 sub-diagram.

UX as part of the team in SAFE 4.0

Agile Link:

This article is not to devalue UX at all. This is proven by the entry on my Agile poster whereby UX Design has always be listed as an activity long before this article was written. [10]. In fact it is to show that while Agile UX is a misnomer this is only because UX activity is encompassed as a part of Agile deliveries rather than in separation of it.

References:

[1] Agile UX: http://studio.uxpin.com/blog/lean-ux-vs-agile-ux-is-there-a-difference/

[2] UX In an Agile World: http://www.nngroup.com/articles/doing-ux-agile-world/

[3] The UX Problem: https://boagworld.com/design/the-problem-with-agile/

[4] Agile UX: http://www.uxmatters.com/mt/archives/2015/09/agile-ux.php

[5] UX SAFe 4.0: http://www.scaledagileframework.com/ux/

[6] UX Guide: http://boxesandarrows.com/the-ux-professionals-guide-to-working-with-agile-scrum-teams/

[7] Don’t do agile, be agile: http://sdtimes.com/dont-do-agile-be-agile/

[8] The Culture: http://www.smashingmagazine.com/2011/10/how-to-build-an-agile-ux-team-culture/

[9] So Agile Together: http://uxmag.com/articles/so-agile-together

[10] Agile Poster:
https://agiledogma.blogspot.co.uk/2014/04/agile-development-poster-there-are.html

[11] Agile UX Sprint:

http://www.slideshare.net/DerTommes/agile-ux-jira-confluence-community-day-2013