Skip to content

Feed aggregator

Installing a VSTS Build agent on Mac OSX

Xebia Blog - Mon, 02/13/2017 - 17:36
Today I needed to install the VSTS Build Agent on a Mac Mini in the office so we can build the IPhone App. The great part of the new build infrastructure in VSTS is that it is Cross Platform and we CAN do that. Just download the agent and run the command provided in the interface.
Categories: Companies

Make Them Grow

Scrum Expert - Mon, 02/13/2017 - 17:16
There might exist some lonely standalone software developers that create software without any other person involved, but my guess is that there are not many of them. Communication is an essential skill in software development, testing and project management… and life. As feedback is a key communication tool, I was therefore very interested when I stumble on this book about feedback written by an Agile coach. “Make Them Grow by Giving Feedback People Apply” is not a long book to read, but it deals in a very pragmatic way about the important topic of feedback, both about positive and negative behaviors. As being Agile seems the “way to go” for most software development teams, the values of courage, trust and honesty will all be supported by putting in practice the advice contained in this book. After reading it, I think that it goes way beyond the software development part of our life. You can give it also to your partners and teenagers. You will have a good communication moment by just starting to have a conversation about it. Which bring us back to Agile, where conversations are one the main tool. Reference: Make Them Grow by Giving Feedback People Apply, Michal Nowostawski, CreateSpace, ISBN-13: 978-1539744153 Quotes Think about the results you can achieve by giving people a simple feedback on their contribution to the development of the company. It is relatively easy to do, but if you want to do it even more effectively, read this book to the end. [...]
Categories: Communities

We Need a Map

Agile Tools - Mon, 02/13/2017 - 05:57

map

“I have an existential map. It has ‘You are here’ written all over it.”

-Steven Wright

I happened to be in a cabin one evening after a long day of hunting. The wood stove was blazing and we were all chilling after dinner. The guides were off to one side hanging out together sharing their experiences from the day. It was fun to watch them as they described where they had been and what they had seen. The dialog would go something like this:

“We were down trail X off of the old logging road Y near the fork in the road and we didn’t see anything”
“You mean down past road Z near the bridge, right?”
“No, no, no. We were down logging road Y.”

Around and around they went.

At this point in the conversation they usually resort to hand gestures to further supplement the conversation. This goes on for a while and pretty soon it’s hard to tell whether you are looking at guides trying to tell each other where they were, or perhaps you are looking at a pair of fighter pilots describing their latest dogfight. There are hands waving wildly in the air. It’s Top Gun in the hunting cabin. Voices are raised, and expressions are animated.

And still they can’t seem to simply tell each other where they were. I’m watching all of this and I’m thinking, “These guys need a map.”

I’d laugh, but I see it all the time in software teams. If I’m honest, I catch myself doing it all the time. It seems that even with all the software that we have today, visualizing what we do and sharing it with each other is still a significant problem for us. How often do you find teams working together and trying to describe something – hands waving in the air and all. I guess we’re all future fighter pilots.

Like I said, I think sometimes what we really need is a map. I challenge you to go take a look at the walls in a second grade classroom. You’ll see nothing but maps. Maps of the US. Maps of the parts of a sentence. Maps of numbers. Everywhere there are maps of the knowledge that second graders consider important. What you see on those walls is the cartography of the eight year old mind.

Now go back to your office and look at the walls. What do you see? I’m betting that the walls are completely bare. Maybe you have some of those crappy motivational posters. If you are really lucky there is a map to the fire escape. There are no maps in the office of the typical knowledge worker. Why is that?

All too often we are like the guides in the cabin. We’re struggling to communicate simple concepts with each other – playing Top Gun. Maybe it’s time for a map.


Filed under: Agile, Teams Tagged: cartography, communication, knowledge work, maps, Software, Teams
Categories: Blogs

ReactJS/Material-UI: Cannot resolve module ‘material-ui/lib/’

Mark Needham - Mon, 02/13/2017 - 00:43

I’ve been playing around with ReactJS and the Material-UI library over the weekend and ran into this error while trying to follow one of the example from the demo application:

ERROR in ./src/app/modules/Foo.js
Module not found: Error: Cannot resolve module 'material-ui/lib/Subheader' in /Users/markneedham/neo/reactjs-test/src/app/modules
 @ ./src/app/modules/Foo.js 13:17-53
webpack: Failed to compile.

This was the component code:

import React from 'react'
import Subheader from 'material-ui/lib/Subheader'

export default React.createClass({
  render() {
    return 
    Some Text
    
  }
})

which is then rendered like this:

import Foo from './modules/Foo'
render(Foo, document.getElementById("app"))

I came across this post on Stack Overflow which seemed to describe a similar issue and led me to realise that I was actually on the wrong version of the documentation. I’m using version 0.16.7 but the demo I copied from is for version 0.15.0-alpha.1!

This is the component code that we actually want:

import React from 'react'
import Subheader from 'material-ui/Subheader'

export default React.createClass({
  render() {
    return 
    Some Text
    
  }
})

And that’s all I had to change. There are several other components that you’ll see the same error for and it looks like the change was made between the 0.14.x and 0.15.x series of the library.

The post ReactJS/Material-UI: Cannot resolve module ‘material-ui/lib/’ appeared first on Mark Needham.

Categories: Blogs

Force uninstall Visual Studio 2017 Release candidates

Xebia Blog - Sun, 02/12/2017 - 12:56

If you, like me, are stuck trying to upgrade Visual Studio 2017, then you may only get unblocked by removing everything and starting afresh. Since Visual Studio 2017 is still in Release Candidate and not final, this is something we may have to deal with from time to time. But when the "uninstall" button in […]

The post Force uninstall Visual Studio 2017 Release candidates appeared first on Xebia Blog.

Categories: Companies

Add :8080 to your TFS 2017 bindings after upgrading to SSL

Xebia Blog - Sun, 02/12/2017 - 12:40

Because TFS 2017 allows authentication with Personal Access Tokens (PAT) it's recommended to upgrade to SSL if you were still on port 80. The installer will even help with the configuration and can add a redirect from port :80 to :443. It doesn't add a a redirect from port :8080 though, so your users may […]

The post Add :8080 to your TFS 2017 bindings after upgrading to SSL appeared first on Xebia Blog.

Categories: Companies

Refactoring Towards Resilience: Evaluating RabbitMQ Options

Jimmy Bogard - Fri, 02/10/2017 - 19:50

Other posts in this series:

In the last post, we looked at dealing with an API in SendGrid that basically only allows at-most-once calls. We can't undo anything, and we can't retry anything. We're going to find some similar issues with RabbitMQ (although it's not much different than other messaging systems).

RabbitMQ, like all queuing systems I can think of, offer a wide variety of reliability modes. In general, I try to make my message handlers idempotent, as it enables so many more options up stream. I also don't really trust anyone sending me messages so anything I can do to ensure MY system stays consistent despite what I might get sent is in my best interest.

Looking back at our original code:

public async Task<ActionResult> ProcessPayment(CartModel model) {  
    var customer = await dbContext.Customers.FindAsync(model.CustomerId);
    var order = await CreateOrder(customer, model);
    var payment = await stripeService.PostPaymentAsync(order);
    await sendGridService.SendPaymentSuccessEmailAsync(order);
    await bus.Publish(new OrderCreatedEvent { Id = order.Id });
    return RedirectToAction("Success");
}

We can see that if anything fails after the "bus.Publish" line, we don't really know what happened to our message. Did it get sent? Did it not? It's hard to tell, but going to our picture of our transaction model:

Transaction flow

And our options we have to consider as a reminder:

Coordination Options

Let's take a look at our options dealing with failures.

Ignore

Similar to our SendGrid solution, we could just ignore any failures with connecting to our broker:

public async Task<ActionResult> ProcessPayment(CartModel model) {  
    var customer = await dbContext.Customers.FindAsync(model.CustomerId);
    var order = await CreateOrder(customer, model);
    var payment = await stripeService.PostPaymentAsync(order);
    await sendGridService.SendPaymentSuccessEmailAsync(order);
    try {
        await bus.Publish(new OrderCreatedEvent { Id = order.Id });
    } catch (Exception e) {
        Logger.Exception(e, $"Failed to send order created event for order {order.Id}");
    }
    return RedirectToAction("Success");
}

This approach would shield us from connectivity failures with RabbitMQ, but we'd still need some sort of process to detect these failures and retry those sends later on. One way to do this would be simply to flag our orders:

} catch (Exception e) {
    order.NeedsOrderCreatedEventRaised = true;
    Logger.Exception(e, $"Failed to send order created event for order {order.Id}");
}    

It's not a very elegant solution, as I'd have to create flags for every single kind of message I send. Additionally, it ignores the issue of a database transaction rolling back, but my message is still sent. In that case, my message will still get sent, and consumers could get events for things that didn't actually happen! There are other ways to fix this - but for now, let's cover our other options.

Retry

Retries are interesting in RabbitMQ because although it's fairly easy to retry my message on my side, there's no guarantee that consumers can support a message if it came in twice. However, in my applications, I try as much as possible to make my message consumers idempotent. It makes life so much easier, and allows so many more options, if I can retry my message.

Since my original message includes the unique order ID, a natural correlation identifier, consumers can have an easy way of ensuring their operations are idempotent as well.

The mechanics of a retry could be similar to our above example - mark the order as needing a retry of the event to be raised at some later point in time, or retry in the same block, or include a resiliency layer on top of sending.

Undo

RabbitMQ doesn't support any sort of "undo" natively, so if we wanted to do this ourselves, we'd have to have some sort of compensating event published. Perhaps an event, "OrderNotActuallyCreatedJustKiddingAboutBefore"?

Perhaps not.

Coordinate

RabbitMQ does not natively support any sort of two-phase commit, so coordination is out.

Next steps

Now that we've examined all of our options around the various services our application integrates with, I want to evaluate each service in terms of the coupling we have today, and determine if we truly need that level of coupling.

Categories: Blogs

Why I Use a Paper Kanban Board

Johanna Rothman - Fri, 02/10/2017 - 17:37

My most recent post about how to Visualize Your Work So You Can Say No showing a couple of different kanbans was quite popular. Several people ask me how I use my personal kanban.

I use paper. Here’s why I don’t use a tool:

  • I am too likely to put too much into a tool. I put all this week’s work, next week’s work, next month’s and next year’s work, even though I’m not going to think about anything that far out. Paper helps me contain my To Do list.
  • When I collaborate with others, they want to break down the stories (large as they may be) into tasks. No!! I can’t take tasks. I need to see the value. See my post about From Tasks to Stories with Value.
  • I change my board, depending on what’s going on. I often have a week-based kanban because I retrospect at the end of the week. I often—not always—have a “today” column.

This is what my board looks like this week. it might look like this for a while because I’m trying to finish a book. (I have several more books planned, so yes, I will have a bunch of work “in progress” for the next several months/rest of the year.)

I have several chapters in This Week. I have two chapters in “Today:” That helps me focus on the work I want to finish this week and today. As a technical editor for agileconnection.com and as a shepherd for XP 2017, I have work in “Waiting to Discuss.” I will discuss other people’s writing.

Earlier this week, I had interactions with a potential client, so that work is now in Waiting for Feedback. Sometimes, I have book chapters there, if I need to discuss what the heck goes in there and doesn’t go in a chapter.

I haven’t finished much yet this week. I am quite close on two chapters, which I expect to finish today. My acceptance criteria is ready for my editor to read. I do not expect them to be done as in publishable. I’ll do that after I receive editorial feedback.

Could I do this on an electronic board? Of course.

However, I limit my WIP by staying with paper. I can’t add any more to the paper.

Should I have WIP limits? Maybe. If I worked on a project, I would definitely have WIP limits. However, the fact that I use paper limits what I can add to my board. If I notice I have work building up in any of the Waiting columns, I can ask myself: What can I do to move those puppies to Done before I take something off the Today or To Do columns?

I’ve been using personal kanban inside one-week iterations since I read Benson’s and Barry’s book, Personal Kanban. (See my book review, Book Review: Personal Kanban: Mapping Work | Navigating Life.

I recommend it for a job search. (See Manage Your Job Search and  Personal Kanban for Your Job Hunt.

You should use whatever you want as a tool. Me, I’m sticking with paper for now. I don’t measure my cycle time or lead time, which are good reasons to use an electronic board. I also don’t measure my cumulative flow, which is another reason to use a board.

I do recommend that until you know what your flow is, you use paper. And, if you realize you need to change your flow, return to paper until you really understand your flow. You don’t need a gazillion columns, which is easy to do in a tool. Use the fewest number of columns that help you achieve control over your work nad provide you the information you need.

Question for you: Do you want to see a parking lot board? I have images of these in Manage Your Project Portfolio, but you might want to see my parking lot board. Let me know.

Categories: Blogs

Migrate a complete Git Repository from TFS to VSTS

Xebia Blog - Fri, 02/10/2017 - 12:10
I am migrating some Git repositories from a TFS server to VSTS. Moving a Git repo including all the history is very simple fo course. Since Git is a Distributed Source Control repository. But I always forget the syntax of moving the “complete” Git repository at once. With all the branches, tags etc. So here
Categories: Companies

Scandinavian Agile, Finland, Helsinki, March 2 2017

Scrum Expert - Fri, 02/10/2017 - 09:15
The Scandinavian Agile Conference is a two-day event organized by Agile Finland and focused on Agile software development and Scrum project management. It takes place in Helsinki and discusses Agile organizations, state of the art in programming practices and Agile coaching. In the agenda of the Scandinavian Agile conference you could find topics like “Risky Business”, “How kanban saved a Salvation Army hospital in Indonesia”, “Refactoring Orgs – How to drive change where it is least expected”, “Traditional leadership myths – and how to break them”, “Cynefin for test planning – Cynefin to the rescue for those times when test strategy is decoupled from context”, “Flow and Experimentation: How Unity Ads Grows Software”, “The IT Risk Manager – Managing Risk using Real Options”, “Transforming the software development industry”, “Clarity before speed: Plan-Do-Check-Act (PDCA) applied in practice”, “The best companies are led by dreams. In the future at least.”, “Stop scaling… Start growing an agile organization!”, “NAPA Agile Story: From Zero to Hero in Two Years”, Web site: http://scan-agile.org/ Location for the Scandinavian Agile conference: Wanha Satama, Pikku Satamakatu 3-5, 00161 Helsinki, Finland
Categories: Communities

Socrates Canaries, Gran Canaria, Spain, April 6-9 2017

Scrum Expert - Fri, 02/10/2017 - 09:00
Socrates Canaries is the Spanish stage of the International Software Craftsmanship Gathering, a series of events for open-minded software developers who want to improve their craft and the software industry as a whole. The local Software Craftsmanship community in the Canary Islands organizes it. The agenda of the Socrates Canaries International Software Craftsmanship Gathering follows the rules of the open conference where the participants create themselves the schedule of the event. Proposals are presented during the event itself in the mornings, and voted by the participants right after. This event is not a hackaton and it’s not about a particular technology, a library or a programming language. It is more about methods, practices, values, principles, and professionalism. Web site: https://www.socracan.com/ Location for the Socrates Canaries International Software Craftsmanship Gathering conference: NH Imperial Playa, Calle Ferreras, 1, 35008 Las Palmas de Gran Canaria, Las Palmas, Spain
Categories: Communities

Scrum vs. Kanban vs. ADKAR vs. Kotter: Change Management

Learn more about transforming people, process and culture with the Real Agility Program

The battle of the organizational change management approaches!

Check out the presentation I did last night at Agile Mississauga Meetup.

20170208 Agile Mississauga Meetup – Change Approach Characterization Model

I describe a model for understanding change management approaches and deciding which ones to use for your situation.  I also look briefly at Positive Deviance and Appreciative Inquiry.

Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
Facebooktwittergoogle_plusredditpinterestlinkedinmail

The post Scrum vs. Kanban vs. ADKAR vs. Kotter: Change Management appeared first on Agile Advice.

Categories: Blogs

Visualize Your Work So You Can Say No

Johanna Rothman - Thu, 02/09/2017 - 22:43

Most people I know—even the people supposedly using agile—have too much work to do. You have project work. You have support work, formal for customer support or sales, and informal for your colleagues. You have reports to write or file, time cards to fill out, or other periodic events.

You need a way to say no to more work.

I wrote an article for Better Software, which is now online. See Saying No to More Work. (You need to register for the site to see the article. No charge for registration.)

One person wanted to see the kanban boards I referred to in the article. I am happy to show them to you here.

These are two potential kanban boards. The one on the left is the basic personal kanban board. Note that there are no WIP (Work in Progress) limits (yet) on this board. I would add WIP limits. Especially if I wanted to convince my manager I was doing too much work.

On the right,  you can see a disaster of a personal kanban board. There are many items To Do, three in Progress and a total of six stuck in various Waiting states. Yes, I had a board that looked like this many years ago. Then, I made a picture on a piece of paper and explained to my boss I was just one person. What did he want me to do and not do?

Now, given what I know, I would add WIP limits to each column.

If you want to see the project portfolio images for how I start at the organization level: the calendar view and kanban view, see Manage Your Project Portfolio at the Prags. At the end of the blurb, there’s a link to the quick start guide, which has just two of the images in the book. (I included many possible ways to visualize the project portfolio in this edition of the book.)

Here’s the key idea: Don’t take on more work than you can complete in a reasonable amount of time. Don’t multitask. Instead, see what your work is and how you might discuss it with your manager.

Categories: Blogs

How HR Can Save or Destroy Agile

Learn more about transforming people, process and culture with the Real Agility Program

“Business engagement alone is a necessary but not sufficient condition for Agile to succeed”

It’s taken a while but now it’s well understood amongst seasoned Agile practitioners that Business engagement is necessary for successful Agile implementations. Just when we thought engaged Business owners were enough, we’re now realizing Business engagement alone is not sufficient. The impact of corporate shared services, especially Human Resources (HR), on Agile adoptions or transformations are often overlooked. In fact, Agile practitioners often bypass HR in their zeal to quickly change the way they work and the related people processes.

“Companies are running 21st century businesses with 20th century workplace practices & programs”

– Willis Towers Watson

It’s not just IT departments practicing Agile but 21st century businesses overall that are characterized by flatter organizations and an insatiable appetite for small ‘a’ agility. Agility that is pushing and breaking the envelope of current HR processes and tools. Agile individuals and teams are very vocal when it comes to calling out technical obstacles in their way. The same could be said when it comes to HR related obstacles that impact Agile individuals and teams. If we listen, here’s what we would hear:

  • “Can we team interview the candidate for attitude and fit?”
  • “I was an IT Development Manager. What’s my role now?”
  • “My manager doesn’t see half of what I do for my team. How can she possibly evaluate me?”
  • “With no opportunity for promotions in sight, how can I advance my career?”
  • “Why do we recognize individuals when we’re supposed to be focused on team success?”
  • “Charlie’s not working out. Can we as the team fire him?”

As the volume increases, how will HR and HR professionals respond?

“2016 will be the year of Agile HR … most HR teams have no clue what Agile HR means”

– HR Trend Institute

The reality is that most HR teams have no clue what Agile is, never mind how it will ultimately rock their world. Most Agile initiatives emerge from the grass-roots or are driven independently by IT functions with little to no involvement from HR. HR  sits on the sidelines and watches IT “do their thing”. There is a misconception that Agile exclusively falls under the IT domain; overlooking the fact that the core of Agile is about the people and culture – the sweet spots of the HR profession.

There are three significant change movements gaining momentum:

  1. Reinventing the way we work – whether it’s IT adopting Agile or an organization becoming more nimble.
  2. Reinventing HR – where HR is moving beyond its historical focus on basic people administration, compliance and transactions to a valued place at the executive table; ensuring context and alignment across the business to generate Customer delight.
  3. Reinventing organizations – as the level of human and organizational consciousness evolves from valuing meritocracy, accountability and innovation to valuing self-management, wholeness and evolutionary purpose. (See “Reinventing Organizations” by Frederic Laloux: http://www.reinventingorganizations.com/)

All three have the common denominator of people; an integral part along the entire timeline of each movement. As these three movements overlap – at the intersection – will be HR. So, who better to help navigate the emerging paths of each change than “the People’s people”?… otherwise known as “HR”.

An analysis of the Human Resources Professionals Association’s (HRPA) Competency Framework shown below can help guide which HR competencies will have the greatest impact (on a scale of 1 to 10) on Agile.

“How do we get HR started towards their destiny?”

If you’re an Agile team member, invite HR to start a conversation about what Agile is and how they can help you and the team.

If you’re an HR professional, here are some suggestions:

  • Learn about Agile
  • Visit with your Agile teams during sprint reviews or daily scrums
  • Talk to your friends and colleagues about their Agile experiences and challenges
  • Review in-progress HR process & tool changes through an Agile lens
  • Partner with IT and other Agile implementation stakeholders to guide the success of Agile

To help HR take the first step, here are some suggested Agile learning resources:

It’s time for HR to get off the sidelines and get in the game.  HR needs to be a “friend” to Agile, not perceived as a “foe”.

Borrowing from a Chinese proverb,

When the winds of change blow, some will build walls while others build windmills… the harnessing of your greatest natural resource, your people, into power.

Build windmills.

Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
Facebooktwittergoogle_plusredditpinterestlinkedinmail

The post How HR Can Save or Destroy Agile appeared first on Agile Advice.

Categories: Blogs

Insights into Agile Transformation Success, Part 1

BigVisible Solutions :: An Agile Company - Thu, 02/09/2017 - 18:00
Agility at the Leadership & Organization Layers

Contributors: Mike Dwyer and Richard Lowery

Throughout 2016, SolutionsIQ helped a growing number of companies successfully kick off and execute many large-scale Agile transformations. Having done this now with dozens of enterprises, we decided to retrospect on some of the common elements of a successful Agile transformation. We’ve summarized our findings along the Five Layers of Agile Transformation (read my blog “Leading Agile Change: Proven Change Models for Agile Transformation” for more on this):

Five Layers of Agile Transformation

  1. Leadership – The traditional industrial-age management style (e.g. Taylorism) is not effective for maximizing performance in a modern, digital organization of knowledge workers. Modern pressures to move and change fast require a different mindset, one that engages employees and challenges them to exploit innovation for competitive advantage. Agile leadership facilitates the emergence of organizational constructs capable of adapting in the face of ambiguity and constant change. The Agile leader exhibits leadership styles that create a culture of transparency, decentralization, engagement, collaboration and accountability.
  2. Organization – Business Agility refers to an organization’s ability to sense and respond to change in ways that allow it to thrive and innovate. Understood in this way, organization-wide agility is constituted by a set of capabilities. These capabilities are embedded within the organizational structures, policies, and practices, as well as within the cultural beliefs and individual mental models through which an organization functions. This includes on-boarding, employee reviews and incentives; finances and accounting; and everything that enables the enterprise to operate as a healthy living organization.
  3. Product & Business – How clear is the product strategy to the people that are implementing it? What is the connection between the strategy and the daily software development work? Crucial for this connection is the Product Owner role and Product Management skill sets and the way that the enterprise specifies and prioritizes work for the software development team.
  4. Delivery – Agile began as a way to speed up software product delivery and as a result this is the area that is (unfortunately) considered the full extent of what is possible with Agile. As seen in our paradigm, however, the Delivery layer is only one segment that benefits from Agile transformation. Focusing on the practices and processes of teams and groups of teams delivering a project, program or product, Delivery encompasses how well individual teams and sets of teams are using Agile frameworks like Scrum and Kanban, how Lean principles are being applied to value streams, and how successfully we are applying scaling patterns and frameworks like Large-Scale Scrum (LeSS) and the Scaled Agile Framework (SAFe).
  5. Execution – The purpose of Agile is to deliver high-quality value to the customer quickly. At the foundation of this product creation pyramid are the technical execution practices and principles that enable development teams to produce high-quality products. This includes the technical practices used in constructing, verifying, validating, and deploying software-based products, which are known in Agile as Extreme Programming (XP) and, more recently, DevOps. Executing within a disciplined Agile framework across the whole value stream can help improve project management discipline, value delivery and predictability. It helps organizations to identify gaps in their capabilities and to highlight impediments that prevent them from achieving peak performance.

In order for an Agile Transformation to provide lasting transformative results, the employed approach must be holistic and comprehensive. When we help organizations layout their Agile Transformation strategy, we typically anchor that strategy around these five major dimensions of capabilities. Now that we know what the goal is, let’s look at each of these five dimensions in a little more detail to reveal some learning insights into the patterns we have observed in enterprises achieving lasting results with Agile transformation. In this post, we consider the first two layers, Leadership and Organization.

Leadership

In addition to adopting new leadership behaviors and styles that are congruent with the modern expectations of knowledge workers, leaders of organizations in the middle of a successful Agile transformation have committed to a few key leadership activities, starting with a clearly articulated vision of the future state you are trying to reach. Questions to pose to your board and leadership include:

  • Why is the company undertaking an Agile Transformation in the first place?
  • Is it to achieve parity with peers?
  • Is it to leapfrog the competition in terms of time to market and/or quality?
  • Is it to achieve a level of disruptive innovation and enter new markets?

Being clear on “why” is important, as is making sure the entire enterprise from top-level leadership to middle management and down into delivery teams is aligned and bought into that vision. When you achieve that level of alignment, you can realize some pretty far-reaching and transformative future states.

Another best practice we have observed is establishing a communication plan. This is more than just a broadcast from leadership; it’s a bidirectional feedback loop that communicates intent, invites and receives feedback transparently, and objectively measures progress.

Lastly, one of the other key success indicators for an Agile Transformation is a greater degree of empowerment throughout the enterprise:

  • Leaders empower middle managers to resolve problems at the sub-executive level and only intervene when management escalates issues.
  • Management empowers teams to provide guidance in terms of best practices to yield optimal results and only intervenes when the team escalates issues.
  • Team members empower each other to be informed about what high quality means at the development level and how to achieve it. Team members are also empowered to request resources to achieve their goals while actively radiating progress.

This is no easy task. It takes a well-conceived strategy communicated by a dedicated leadership continuously and unwaveringly in order to achieve the desired results. That is partly why, in “The Third Wave of Agile”, SolutionsIQ Chairman Charlie Rudd calls for the role of management and leadership to be redrafted to account for the explosive growth of Agile teams and Agile adoption in general.

Naturally, leadership cannot accomplish anything without individuals actually doing the work, so let’s turn to the people in the organization. In particular, we look now at some of the key success indicators in the Organization layer.

Organization

For many enterprises, Agile Transformation is the largest organizational change it will ever undertake. The results are deep and broad, including structural and behavioral changes, as well as the introduction of new mindsets that may fundamentally alter the overall culture of the organization — and in a good way.

However, these sweeping changes don’t just happen. In order to become a learning organization with high degrees of transparency and collaboration, the enterprise needs to have a strategy for designing, executing and maintaining change. Many of the organizations enjoying success with Agile Transformation owe it in part to using some classic organizational change management models and frameworks, including:

  • John Kotter’s 8-Step model
  • Prosci’s ADKAR framework
  • Jason Little’s Lean Change Management, a newer emergent model that is starting to get a lot of attention

What makes organizational change management so thorny is that people – many, many people, all with their own capabilities and fears – are the focus. Change, as will surprise no one, is something that few people enjoy. Often leadership, specifically, creates a corporate culture against change, because fluctuations of even the smallest degree can affect the bottom line. Operating under a traditional world view where the market is wieldy and fluctuates little to not at all, stability is the only important metric. However, in today’s continuously changing business world, only those institutions – and those people – who are capable of learning and growing and changing as quickly as possible have a horse left in the race. In other words, organizational change management must be a part of any successful enterprise’s survival kit. Otherwise, any and all success will be short-lived.

This is where departments traditionally seen as “support” (HR, finance, recruiting — even sales and marketing) are brought into the change equation. In organizations who want to attract people resilient to and even adept at change, for example, human resources and recruiting has to be better at finding and keeping these candidates. In addition, to achieve long-lasting changes to mindsets, culture and behavior, enterprises must fundamentally rethink their overall incentive programs — and this is exactly the trend we are witnessing with many of our clients. The corporate value of collaboration becomes suspect when individuals are rewarded and promoted at the expense of their own team mates. Fortunately, we have seen a handful of our clients switch to more team-based rewards so as not to undermine their hard-earned successes achieved through Agile transformation. Positive, managed changes throughout the organization like these require consistency and transparency, which creates an even stronger imperative to leverage tried and true change management models.

Summary

So as you can see, there are a number of dimensions to a successful Agile Transformation. We’ve explored the first two, Leadership and Organization:

  • Leadership – Agile leaders exhibit leadership styles that create a culture of transparency, decentralization, engagement, collaboration and accountability. Enterprises who have success with Agile Transformation include a focus on Leadership as part of the overall transformation strategy.
  • Organization – The success of any enterprise lies in the people on staff. Enterprises who have success with Agile Transformation use change management frameworks and tools in order to manage and maintain change in the direction of the desired organizational culture. These enterprises also update their approach in support roles like HR and recruiting.

In the second part of this series, we continue the discussion by exploring the remaining three dimensions of a successful Agile Transformation: Product, Delivery and Execution.

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

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

Categories: Companies

Running Windows Containers on Azure Service Fabric - Part II

Xebia Blog - Thu, 02/09/2017 - 13:39
The previous post showed how you can create an unsecure Service Fabric test cluster in Azure, and how to run a Windows Container on it. In this follow up post, I'll show you what's going on inside the cluster, using the Docker command line. Knowledge about this can be very useful when troubleshooting. Verify your container
Categories: Companies

Running Windows Containers on Azure Service Fabric

Xebia Blog - Thu, 02/09/2017 - 13:37
Background Since the release of Service Fabric runtime version 5.4.145, Microsoft added a (preview) feature to run Windows Containers on Windows Server 2016. The Linux version already supported this for a while. This post explains why Containers are useful and how to get it to work. What is Service Fabric? Most companies have a lot of applications
Categories: Companies

The value of coaching

Growing Agile - Thu, 02/09/2017 - 10:27
If you’ve never been coached you might not know that the role of a coach is not to offer advice, judgement, or solutions. Their role is to listen deeply, ask powerful questions, help you explore answers you already have within yourself, and help you craft a definitive action that you then take. We recently attended […]
Categories: Companies

Certified ScrumMaster Training Workshop in Toronto—April 18-19

Notes from a Tool User - Mark Levison - Thu, 02/09/2017 - 01:01
Agile Pain Relief presents a two-day Certified ScrumMaster Workshop in Toronto—April 18-19 taught by certified ScrumMaster Trainer Mark Levison.
Categories: Blogs

Certified ScrumMaster Training Workshop in Montreal—April 10-11

Notes from a Tool User - Mark Levison - Thu, 02/09/2017 - 00:51
Agile Pain Relief presents a two-day Certified ScrumMaster Workshop in Montreal—April 10-11 taught by certified ScrumMaster Trainer Mark Levison.
Categories: Blogs

Knowledge Sharing


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