Skip to content

Feed aggregator

Article 9 in SAFe Implementation Roadmap series: Coach ART Execution

Agile Product Owner - Mon, 03/13/2017 - 03:54
Click to enlarge.Click to enlarge.

The ninth ‘critical move’ in the SAFe Implementation Roadmap series, Coach ART Execution, is when you really start to capitalize on the investment that has been made developing SPC change agents, and training stakeholders in the new way of working.

At this stage of the implementation, the first big events are now in your rear view mirror. You’ve launched the first Agile Release Train (ART), and held the first Program Increment (PI) planning session. The result of all this effort is an empowered, engaged, and aligned team-of-Agile-teams ready to begin building solutions that deliver value.

There’s much at stake now, and how you proceed from this point on will dictate how well the teams embrace the new culture. You’ve set in motion a new set of practices and principles, and planted the seeds of a new Lean-Agile mindset, but that alone does not make everyone magically ‘Agile.’ It simply provides the opportunity to begin the journey of becoming Agile.

It’s now time to begin the cycle of continuous improvement that will affect the value you’re delivering to your customer, as well as the culture transformation that is taking place internally. You could think of the first ART like a child learning how to walk. It needs a good amount of encouragement, guidance, and feedback to realize its full potential. That’s where ART and team coaching come into play.

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

Announcing the X-Matrix Jigsaw Puzzle

AvailAgility - Karl Scotland - Fri, 03/10/2017 - 17:58

fitting the pieces together

The X-Matrix Jigsaw Puzzle is what I call the exercise I use in Strategy Deployment workshops to help people experience creating an X-Matrix in a short space of time. It consists of a pre-defined and generic set of “pieces” with which to populate the various sections, deciding which pieces should go where, and how they fit together.

I’ve just created a page to make this available under Creative Commons Attribution-ShareAlike 4.0 International.  If you try it out, please let me know how you get on!

Categories: Blogs

Selecting A Node.js Image for Docker

Derick Bailey - new ThoughtStream - Thu, 03/09/2017 - 22:57

Before you begin to run your Node.js application in a Docker container, or even build the app into a container, you have to answer an important question and make a key decision:

Which base Node.js image for Docker do I choose for my app?

Choosing nodejs docker image

The easy answer – and probably the most common one – is to specify the Node.js version you wish to use and take the full image for that version.

This is the mostly safe answer as it will give you a container in which you can do practically anything without having to install or configure any other tools; only your code.

It may not be the right choice, as you’ll see below. But in general it’s a safe choice as it includes a stable release of the Debian linux system (as most Node.js images do) with many pre-configured tools and dependencies.

Select Your Node.js Version, First

Before you select which version of Linux you want to build from, it’s important to pick your Node.js version.

There’s really only one thing you need to know when doing this. And that is:

Do Not Specify FROM node As Your Base Image

If you specify “FROM node” without a version number tag, you will always be given the latest version of Node.js.

While this may sound like a great thing, at first, you will quickly run into headaches when you rebuild your image and find your application doesn’t run because a new release of Node.js no longer supports an API you’re calling or makes other changes.

You should always specify at least a major version number tag.

More realistically, you should specify a minor version as well.

You can optionally specify a patch number but this is not as necessary. There are typically very few breaking issues between patch releases.

Now that you have your Node.js version selected, it’s time to deal with the specific linux distribution and image options.

Selecting Your Linux Distribution

In addition to the major Node.js version numbers, there are other options from which you can choose for your image, including these tag name extensions:

  • the default image (aka ‘jessie’)
  • -slim
  • -onbuild
  • -wheezy
  • -boron
  • -alpine
  • -argon
  • (and others in various combinations)

But before you make your decision on which image to use, you should know that the decision is not permanent.

In fact, it’s fairly simple to change the image from which you’re building. In truth it’s often far more challenging to change the Node.js version than to change the base image from which you build.

Don’t take the choice too seriously, then. Do consider a few of the following points on what each of the many images offers, though.

Wheezy, Jessie, what?

As mentioned before, most of the Node.js images are built from Debian linux. This is a very stable, very popular distribution of Linux.

This is also where many of these odd names come from.

Like many long-living projects, Debian uses code names for various major versions of it’s operating system. You can find a list of which version is what name on the Debian release page.

Not all of the Node.js images are built from Debian, however. There are a few other image, including distributions of Alpine linux and Scientific Linux to name a few.

However, you only need to care about 2 of these Linux distribution options, in my opinion: Debian and Alpine.

Selection: Full, Slim or Alpine?

Unless you’re looking for a very specific version of Linux and Node.js, for a very specific reason, I would stick with either the latest version of Debian (currently “jessie”), or Alpine Linux.

This drops your choice for the base image down to 3.

  • The full image (with version number tag!)
  • The ‘-slim’ image
  • The ‘-alpine’ image
With the choices narrowed down, it’s a bit easier to find the right option for you scenario. Full vs `-slim`

Both the full Node.js image and the ‘-slim’ image are built from Debian Linux (v8 “jessie” at the time of writing this). The major difference being the tools and libraries that are installed by default.

If you travel the hierarchy of Dockerfile builds and tags, you’ll find that the full version of the image builds from the same core ‘jessie:curl’ tag as the slim version.

The full version, however, adds a significant number of tools, including:

  • source controls software, such as git, subversion, bazaar, and mercurial
  • runtime libraries and build tools like make, gcc, g++, and others 
  • libraries and API sets such as imagemagick, a dozen other lib* libraries), and others

The end result of the tools and libraries that are installed into the full Node.js image is an image that starts at 650MB.

But, in spite of it’s size the full Node.js image can save a significant amount of drive space if you are using it for multiple images. This is one of the beautiful parts of how Docker manages images.

If you need these libraries and tools, then, this is a great option. If you’re building many images that need these tools, this is an especially important option.

If, however, you don’t need these tools and libraries – or you don’t have a lot of hard drive space and want to be more in control of the image contents – then the ‘-slim’ version of the image is probably what you want. This version runs around 250MB to start.

The third option from which you should choose is the ultimate in small images, however.

Alpine Linux: ‘-alpine’

Alpine Linux is a distribution that was almost purpose-built for Docker images and other small, container-like uses. It clocks in at a whopping 5MB of drive space for the base operating system.

By the time you add in the Node.js runtime requirements, this image does move up to around 50MB in space. But even at 10x the original Alpine size, it’s still 1/5 the size of the the `-slim` option.

My Recommendation: Alpine Linux

For my work, and for the work that I’m putting into my WatchMeCode guide to building Node.js apps in Docker, I prefer Alpine linux.

Alpine provides a great balance of incredibly small size with options for adding the build tools and libraries that you need. Even with a full build tool set installed, it only hits around 200MB. That’s still less than the ‘-slim’ option, while providing native compilation for things like bcrypt and other libraries.

There are a few caveats to note with the Alpine distribution, however.

The largest of which is that you may not be able to run all of your needed libraries. Alpine uses ‘musl libc’ instead of ‘glibc’. While this may not mean much to you right now, it does mean that you can’t install and use the Oracle Node.js driver, among other things.

For the most part, however, Alpine linux is a great distribution to use as a first choice.

And remember, you’re not stuck with the decision you make now. It’s not that difficult to change from Alpine to -slim or the full version, later.

The post Selecting A Node.js Image for Docker appeared first on DerickBailey.com.

Categories: Blogs

Review of: Product Mastery – From Good to Great Product Ownership

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

Note: This review is based on an incomplete pdf copy of Product Mastery that was shared with the reviewer, which therefore limits discussion of the book.

Geoff Watts, author of Scrum Mastery, has now released Product Mastery: From Good to Great Product Ownership, published by Inspect & Adapt Ltd. The book contains two Forewards by Jeff Sutherland and Roman Pichler, both masters in the field of Scrum management.

The prose Watts uses is straightforward and provides an easy and intelligent read even for the layman, with graphs and illustrations that illuminate his ideas.

The book is built around the idea of DRIVEN, an acronym Watts uses to discuss the traits and characteristics of a great product owner. The book uses each letter as headings, i.e. D = Decisive, R = Ruthless, I = Informed, V = Versatile, E = Empowering, and N = Negotiable. Each heading offers pragmatic advice into the many responsibilities of being a product owner. I will give a few snippets of some insights that Watts shares.

In the first section, entitled “Decisive,” Watts creates stories and discussion that show how product owners need to have courage and trust themselves and others to make decisions, often with incomplete information. He gives strategies to make the decision-making process easier, such as reducing the number of options a product master is considering, and prioritizing. He cites Edison as once famously saying, “I have not failed. I’ve just found 10,000 ways that won’t work.”

Under “Ruthless” Watts shares a mantra used by product owners: “If the product is going to fail, then I would rather it fail in month 2 than month 22.” In other words, it is better to develop the wrong thing quickly and get feedback, than wait too long in an effort to make sure no mistakes are ever made.

The third section is called “Informed.” Watts includes a quote by Roman Pichler, author of Agile Product Management with Scrum, who told him: “Customer feedback is the basis for ideas. Customer data is the basis for decisions.” Watts then cites the experience of a company that creates mobile games. Rather than ask for ratings or feedback, the company monitors actual usage of their games.

In “Versatile” Watts advises product owners to “remain flexibly firm.”

Under the last heading, “Negotiable,” he outlines games to play when negotiating attributes of a product. In this section Watts makes it clear that product owners need to be careful to not fall into the trap of being a perfectionist. He writes: “The temptation to just add a little extra here or there is very strong; but those little bits here or there quickly add up and can easily lead to significant delays, not to mention an unnecessarily cumbersome product to support.”

Product Mastery is a book that is sure to attract a wide readership as it provides a balance

between vision, direction and execution. Wisely, Watts is not dogmatic in his style. He gives numerous approaches to the items under a product owner’s watch. He writes: “Great product owners know how to find the right middle ground, one with an appropriate balance of data and intuition – and a good measure of courage.”

I personally will be adding Product Mastery to BERTEIG’s book offerings for our Certified Scrum Product Owner attendees.

Product Mastery: From Good to Great Product Ownership (282 pp)

Table of Contents:

Foreward – Jeff Sutherland

Foreword by Roman Pichler

DECISIVE 26

RUTHLESS 64

INFORMED 102

VERSATILE 144

EMPOWERING 180

NEGOTIABLE 222

Be DRIVEN to Be Great 264

Available at https://www.amazon.ca/s/ref=nb_sb_noss_1?url=search-alias%3Daps&field-keywords=product+mastery

Product Mastery: From Good to Great Product Ownership Mar 1 2017

by Geoff Watts and Jeff Sutherland

Kindle EditionCDN$ 41.94

PaperbackCDN$ 42.18

 

 

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

The post Review of: Product Mastery – From Good to Great Product Ownership appeared first on Agile Advice.

Categories: Blogs

Review of: Product Mastery – From Good to Great Product Ownership

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

Note: This review is based on an incomplete pdf copy of Product Mastery that was shared with the Reviewer, which therefore limits discussion of the book.

Geoff Watts, author of Scrum Mastery, has now released Product Mastery: From Good to Great Product Ownership, published by Inspect & Adapt Ltd. The book contains two Forewards by Jeff Sutherland and Roman Pichler, both masters in the field of Scrum management.

The prose Watts uses is straightforward and provides an easy and intelligent read even for the layman, with graphs and illustrations that illuminate his ideas.

The book is built around the idea of DRIVEN, an acronym Watts uses to discuss the traits and characteristics of a great product owner. The book uses each letter as headings, i.e. D = Decisive, R = Ruthless, I = Informed, V = Versatile, E = Empowering, and N = Negotiable. Each heading offers pragmatic advice into the many responsibilities of being a product owner. I will give a few snippets of some insights that Watts shares.

In the first section, entitled “Decisive,” Watts creates stories and discussion that show how product owners need to have courage and trust themselves and others to make decisions, often with incomplete information. He gives strategies to make the decision-making process easier, such as reducing the number of options a product master is considering, and prioritizing. He cites Edison as once famously saying, “I have not failed. I’ve just found 10,000 ways that won’t work.”

Under “Ruthless” Watts shares a mantra used by product owners: “If the product is going to fail, then I would rather it fail in month 2 than month 22.” In other words, it is better to develop the wrong thing quickly and get feedback, than wait too long in an effort to make sure no mistakes are ever made.

The third section is called “Informed.” Watts includes a quote by Roman Pichler, author of Agile Product Management with Scrum, who told him: “Customer feedback is the basis for ideas. Customer data is the basis for decisions.” Watts then cites the experience of a company that creates mobile games. Rather than ask for ratings or feedback, the company monitors actual usage of their games.

In “Versatile” Watts advises product owners to “remain flexibly firm.”

Under the last heading, “Negotiable,” he outlines games to play when negotiating attributes of a product. In this section Watts makes it clear that product owners need to be careful to not fall into the trap of being a perfectionist. He writes: “The temptation to just add a little extra here or there is very strong; but those little bits here or there quickly add up and can easily lead to significant delays, not to mention an unnecessarily cumbersome product to support.”

Product Mastery is a book that is sure to attract a wide readership as it provides a balance between vision, direction and execution. Wisely, Watts is not dogmatic in his style. He gives numerous approaches to the items under a product owner’s watch. He writes: “Great product owners know how to find the right middle ground, one with an appropriate balance of data and intuition – and a good measure of courage.”

I personally will be adding Product Mastery to BERTEIG’s book offerings for our Certified Scrum Product Owner attendees.

Product Mastery: From Good to Great Product Ownership (282 pp)

Table of Contents:

Foreward – Jeff Sutherland

Foreword by Roman Pichler

DECISIVE 26

RUTHLESS 64

INFORMED 102

VERSATILE 144

EMPOWERING 180

NEGOTIABLE 222

Be DRIVEN to Be Great 264

Available at https://www.amazon.ca/s/ref=nb_sb_noss_1?url=search-alias%3Daps&field-keywords=product+mastery

Product Mastery: From Good to Great Product Ownership Mar 1 2017

by Geoff Watts and Jeff Sutherland

Kindle Edition

CDN$ 41.94

Paperback

CDN$ 42.18

Prime

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

The post Review of: Product Mastery – From Good to Great Product Ownership appeared first on Agile Advice.

Categories: Blogs

Targetprocess Mobile for Android, Releases 2.4 and 2.5

TargetProcess - Edge of Chaos Blog - Thu, 03/09/2017 - 17:07
View and edit Custom Fields from entity details view

Custom fields are widely used by our customers, so we've finally added them into the entity details view on our Android app. You can view and edit Custom Fields of all types (except for the Multiple Targetprocess type, because it’s hardly ever used).

You can find the Custom Fields section in the same place as our main desktop app: scroll down the entity view and you will see Custom Fields panel under the Info panel.

custom-fields

Planned Dates

Since release 2.4, you may notice that Planned Start and Planned End dates have appeared at the bottom of  the ‘Info’ panel. You can now plan work items directly inside the app:

planned-dates

Some other useful improvements include:
  • Added the Initial Estimate field to Epic views and the Run Estimate field into Test Plan views
  • Estimation fields will now display Effort units

If you have anything you want to share with us, just use the Feedback form in the ‘Me’ tab, or send us a message at mobile@targetprocess.com.

Click here to download the Android app.

Categories: Companies

The Tweets You Missed in February

Sonar - Thu, 03/09/2017 - 15:22

Here are the tweets you likely missed last month!

SonarQube Scanner for Jenkins 2.6 adds the support of quality gates in pipeline jobs. https://t.co/GnsSH0PZE8 pic.twitter.com/QnJcZwdmkZ

— SonarQube (@SonarQube) February 28, 2017

SonarC# 5.6 Released: 7 new rules available https://t.co/3fibqDlc5i pic.twitter.com/N5RPoPQhS5

— SonarQube (@SonarQube) February 7, 2017

SonarJS 2.20 Released: track usage of non-existent variables, support of cognitive complexity and more … https://t.co/AY2EWKaZmr pic.twitter.com/wbAhrjywdR

— SonarQube (@SonarQube) February 15, 2017

"SonarLint – Bug hunting season is open" by @_henryju_ https://t.co/HBQqX9C7cp pic.twitter.com/VRjQCRby7x

— SonarLint (@SonarLint) February 20, 2017

SonarLint for Eclipse 2.6 shows issues context and highlights corresponding locations https://t.co/NRWpZwE1Ms pic.twitter.com/TRrFaAbiJa

— SonarLint (@SonarLint) February 27, 2017

Categories: Open Source

Why not just define the solution in advance?

Leading Agile - Mike Cottmeyer - Wed, 03/08/2017 - 22:24

If you’re familiar with our model of organizational transformation, then you know we’re fond of the metaphor of taking a journey in a specific direction, possibly (but not necessarily) ending up at the farthest imaginable point of that journey. We think of the journey as a series of expeditions, each of which aims to fulfill a portion of a vision and plan.

The metaphor is both spatial and temporal. When you picture a group of adventurers embarking on an expedition, the visualization is mainly spatial: They are marching across territory toward a goal that lies on the horizon. The horizon moves ahead of them as they march. Their concept of “the possible” depends on what they are able to see or imagine from their current position and, as they progress, they are able to see and imagine more and more possibilities.

A way forward based on Lean principles involves conducting a series of experiments. Learnings from each experiment inform the design of the next experiment. Always, there’s a goal in mind. Over time, outcomes meet needs more and more effectively. Improvement over time suggests a temporal angle on the “journey” metaphor.

Step-by-step Improvement Over Time

It’s easy to find examples of similar journeys that suggest change over time. One that I find relevant, particularly in larger, well-established IT organizations, is the tale of the Eddystone Lighthouse. You can read about it on Wikipedia. There are also many videos on YouTube about the lighthouse, and it has been featured on the Science Channel program, “Impossible Engineering.”

I see this as an example of a temporal journey of improvement because of the progression of engineering advancements reflected in the series of lighthouses built on the site from 1699 to the present. Similarly, improvement in organizational performance often involves building a series of solutions that incrementally move closer to strategic goals.

…it turns out to be faster, cheaper, and better to find the way forward through a series of experiments than to design the ultimate solution in advance.

Lighthouses and expeditions

It’s easy to get tangled up in a sea of metaphors. Even referring to the situation as a “sea” could be one metaphor too many, were it not for the fact we’re also talking about lighthouses.

This lighthouse at Eddystone was the the first to be built in the middle of the sea and was erected on a rock that which was submerged 20 hours a day. Over the course of history, it was rebuilt four different times, each quite different from its predecessors. Engineers had learned things and materials science had progressed, enabling each successive lighthouse to be better than those that had stood before.

The same pattern occurs in organizational transformation. A Scrum team on a journey from Basecamp 2 to Basecamp 3 will use the Scrum events and artifacts quite differently than a team progressing from zero to Basecamp 1. The more mature team will use Scrum in a lighter-weight fashion than the novice team. For example, they have learned how to level out their work by crafting User Stories of roughly the same size. They’re on their way to dispensing with story-level sizing. Meanwhile, the novice team may still be struggling with separating the notion of size from the notion of time, and they may have difficulty visualizing the possibility that story-level estimation is a crutch that can be made unnecessary by mastering other practices.

Also, the organization surrounding the two teams will be at different levels of proficiency with lightweight methods. You’ll often hear us speak of clarity around the backlog, or words to that effect. An expedition approaching Basecamp 3 will have learned skills in identifying worthwhile initiatives, prioritizing those initiatives, and refining backlogs that are sensible and actionable by program and delivery teams.

It’s more feasible for the delivery teams in the Basecamp 3 expedition to function in a lightweight way than for the novice teams, which are supported by organizations still early on the learning curve, still struggling to reach Basecamp 1. They may not receive actionable backlog items on a consistent basis. Everyone is trying to get a handle on quite a few unfamiliar concepts and methods. Even an advanced team would have challenges in maintaining flow and delivering value without appropriate support from the program and portfolio teams.

The two organizations just can’t build the same kinds of lighthouses. They have to advance one step at a time.

Why not just determine the final solution through research?

Sometimes, people are uncomfortable with this approach. They would prefer it if we could design the “final” solution in advance and then simply implement it. That way, they would have only one sizeable capital investment to make, and they could check the “improvement” box. All done!

An aside: This mentality may be at the root of the numerous attempts to “implement” a framework, such as SAFe or LeSS, and lock it in as the “final state.” Although the proponents of such frameworks are consistent in saying they are meant to be a starting point for ongoing improvement, people tend to try and “implement” a framework as if it were a “solution.” Are they hoping for a magic bullet?

The “implementation” approach may be feasible for relatively small enterprises that have fairly narrowly-bounded goals. When a larger enterprise, that has longstanding habits and entrenched processes, sets a goal to “be more effective” or “be more competitive” or “improve the customer experience” or “be able to pivot quickly,” it’s harder to visualize a Golden End State in a vacuum. Such goals are real and meaningful, but difficult to quantify, and the path to achieving them in the face of an ever-changing competitive landscape is not easy to discern.

Perhaps counterintuitively, it turns out to be faster, cheaper, and better to find the way forward through a series of experiments than to design the ultimate solution in advance. It takes less time and less money to build something, learn from it, discard it, and build another (repeating the sequence several times) than it does to learn all the possibilities and pitfalls of numerous options in advance through “research.” This has been a practical reality for a long time, far longer than the buzzword agile has been in use.

That pesky moving horizon

Now you may be asking, “If you’ve seen this pattern before and you know what to expect, why don’t you just tell us what we need to do to be at Basecamp 5? Let’s start Monday!”

That would be great. Unfortunately, things don’t seem to work that way. Combining the experiences of the LeadingAgile consultants, we’ve seen that approach many times in many kinds of organizations. We’ve tried starting with culture change; with procedural change; with technical practices. We’ve tried driving change top-down; bottom-up; by consensus or invitation; by management dictate. What’s common in those cases is that when people are told what to do, the desired change in mentality doesn’t happen. When people are invited to change their thinking, they simply don’t know how. People remain in the mindset of following orders. The only difference is they’re following different orders than before. The changes don’t penetrate deeply, and they aren’t sticky. People become frustrated with the results, and abandon the effort to change.

It seems to be important that people deeply understand the why of the change. To become aware of some of the possibilities is a good first step, but it isn’t sufficient to create meaningful and lasting improvement. People need to be able to get their heads around the potential benefits and risks of any given change. For that to be possible, they need guidance beyond the limits of their comfort zone…but not too far beyond those limits. Very radical change, introduced suddenly, will only lead to fear and frustration. The only way to reach Basecamp 5 is to walk there, step by step.

Remember the bit about the horizon moving ahead of you? It does. At the outset of the journey, you don’t have enough information to visualize possible end states. There may even be so much organizational “fog” that you can’t really tell which way to turn. The best you can do is set a direction that seems to be consistent with your goals. Then you have to take a deep breath and start walking, pausing to check your compass frequently and adjusting course accordingly.

Maybe the first few lighthouses you build will burn down or be swept away by the sea (or be destroyed by Napoleon’s army, as the case may be), but eventually you’ll build one that nothing and no one can tear down. The key is to be willing to try things that don’t turn out exactly the way you hoped, and learn from those experiences. Just keep going. As long as you have a good compass, you won’t get lost.

The post Why not just define the solution in advance? appeared first on LeadingAgile.

Categories: Blogs

6 Benefits of Kanban for Project Management

Learn how Kanban is being applied as a visual project management tool to help teams visualize, manage, and optimize their work.

The post 6 Benefits of Kanban for Project Management appeared first on Blog | LeanKit.

Categories: Companies

Join Our Product Update Webinar on March 15, 2017!

TargetProcess - Edge of Chaos Blog - Wed, 03/08/2017 - 18:08
Q1 Product Update Webinar graphic

We invite you to join us for our Product Update Webinar on Wednesday, March 15 at 12:00 PM - 1:00 PM EDT.

It's already been a busy year here, and we want to make sure that everyone is up to speed with all the recent changes.  We'll also be going over some of our immediate plans for the future, and there will be a team of Product Specialists available to answer your questions.

At the webinar, you can expect to see a demonstration of all the latest features and improvements, including:

  • lane suggestions and the new "My Recent" tab in the left menu
  • new connectors for integrating Targetprocess with ALM tools such as Jira, TFS, CA Agile Central, and DevOps tools such as Git, GitHub, Jenkins, and many others
  • how to setup the Service Desk and use Custom Request Types to expand its possible use cases
  • improved Project and Team assignments for Person, Team, and Release views
  • the latest releases for our mobile iOS and Android apps, and more

You can register for the webinar here. We hope to see you there!

Categories: Companies

Agile Amped Highlight: Women in Agile

BigVisible Solutions :: An Agile Company - Wed, 03/08/2017 - 18:00

 

Happy International Women’s Day!

109 years ago, born from the struggle against women’s oppression and inequality, 15,000 women marched on New York City. A lot has changed in the last century, but women are still rallying for change and being the change that they themselves want to see. This year’s theme is #BeBoldForChange and SolutionsIQ is humbled and inspired by the bold change we see women in our own industry lead. Just two weeks ago at the inaugural Business Agility conference, our Agile Amped podcast had the opportunity with some of the leading women in our industry to discuss how Agile is affecting so many different areas of the organization — and indeed the world! Agile is penetrating into every aspect of business from who HR hires and incentivizes employees, how leaders lead and cultivate an impassioned following, to how social media has changed everything but especially marketing in ways that only Agile tools and thinking can survive and thrive in. And we are happy and honored to say that women are leading the charge in key areas and innovating solutions to problems that others can’t even begin to grok.

Learn more about the International Women’s Day.

To celebrate our appreciation for women and the International Women’s Day, we’ve curated a playlist of our favorite Agile Amped podcasts with female guests, like repeat guest par excellence Esther Derby who has 6 Rules for Change and Renee Troughton who thinks that performance reviews are often disrespectful. But starting out the list of our most popular Agile Amped podcast of all time, with more than 3,000 views on YouTube, is  the incomparable and highly esteemed Lyssa Adkins, who sat with SolutionsIQ’s Michael Tardiff at Agile2015 to shake out the difference between mentoring and coaching.

Our Favorite Podcasts with Female Guests Mentoring vs Coaching: Show Me the Difference – with Lyssa Adkins

The industry holds that skills in both mentoring and coaching are useful for ScrumMasters, Agile coaches, and managers. Yet the differences between these approaches is not crystal clear for most people. It’s time to show more than tell. In this podcast, Lyssa describes the anatomy of powerful coaching conversations and mentoring conversations, how these skill sets address problems in radically different ways, and providing clarity on when to mentor and when to coach.

Renee Troughton on Uncomfortable Conversations and Agile Transformations

Enterprise Agile coach Renee Troughton believes that pessimism and optimism are additive: lots of horrible moments can give you a pessimistic outlook, while lots of positive moments can yield an optimistic one. “We ride this pessimistic and optimistic wave as individuals based upon the moments that we have in conversations everyday.” Perspective shapes how feedback is received — and that can make an uncomfortable conversation out of sharing simple feedback.

Too often, though, feedback is imposed on people by HR in a performance review, which Renee thinks often comes across as “disrespectful”. Instead, people should be able to communicate to each other the feedback they have. The ideal is to create an environment where feedback is welcome and not delivered in a disrespectful manner. Renee champions patience, mindfulness of how you come across, respect and optimism because when people are ready for feedback, they will seek it out. She recommends having a conversation and, if you’re the one providing the feedback, be aware of what your body language is communicating.

Six Rules for Change with Esther Derby

According to Esther Derby, much of the literature on change is very deterministic, which completely disregards the fundamental tenet that humans, being creatures of evolution, are designed to change. Change is often much slower than hoped for, and more painful than anticipated. After years of work and research, Esther has distilled her experiences into principles for successful transformation into Six Rules for Change. These principles address both the complexity of the organization and the complexity of the human experience of change. They provide a set of touch-points to guide change artists as they support and enable change in their organizations.

Esther also dives into another talk she gave at Agile2015, called “Coaching Flow: Moving Past Resistance.” She says, “People don’t resist change; they resist coercion.”

Author Andrea Fryrear: Agile is Our Only Hope for Modern Marketing

Given the growing level of complexity, scope and audience involvement, from Andrea Fryrear’s perspective, “Agile is our only hope” for modern-day marketing. Her book “Death of a Marketer”(due for release this month) takes a look at the trajectory and cycles of marketing and where it is now. In the book Andrea argues that Agile is the stage in evolution where marketing is at.

At Business Agility 2017, Andrea presented her talk “A Common Sense Journey into Agile Marketing”, in which she shares her experience of the first transformation with her marketing team. She highlights that Agile approaches that work for development teams don’t necessarily work for marketing teams: “Because [of] our challenges, our team structure, our skill sets, it’s really hard to create a truly cross-functional marketer, whereas you can get that in a development team much more easily.” Development teams gravitate to Scrum, which builds on cross-functional team members, whereas Agile marketers find more utility with Lean and Kanban.

 Talent Advisor at IBM CIO Isabella Serg on Agile HR and “the War for Talent”

Isabella Serg got her start in Agile HR in financial services and insurance in Australia. That’s where she learned that agility and adaptability aren’t just an IT or delivery thing. Today, as Talent Advisor at IBM CIO, Isabella focuses on “how to improve people, talent, leadership practices to develop great Agile leaders and attract, develop and retain great Agile talent.” This objective requires bringing an Agile mindset to the HR function — and indeed to all parts of the organization. Isabella is certain that non-IT teams need to be Agile as well to improve their responsiveness. IBM is leveraging organizational agility as a market differentiator because, as Isabella points out, “The war for talent is here… [Incoming young people are] really looking for great leadership, great culture, and great learning and development opportunities.” And this culture centers around the behaviors instilled by leadership. The most important driving focus, regardless of your organizational function (HR, IT, etc.), is “putting the customer at the center of everything we do.”

But Wait — There’s More!

There are hundreds more podcasts with enterprising women and men who are the face of Agile change. Check out our Agile Amped page and, if you haven’t already, make sure to subscribe below!

The post Agile Amped Highlight: Women in Agile appeared first on SolutionsIQ.

Categories: Companies

Get Clarity

Leading Agile - Mike Cottmeyer - Wed, 03/08/2017 - 15:04

Get Clarity

I believe the number one reason for failure or waste is a lack of clarity or understanding. If you get clarity on something, it gives you the freedom to decide if you want to do it or not.  If something is ambiguous, you may agree in principle but you don’t know what you’re really getting yourself into.

OKRs

Firstly, what are your Objectives and Key Results (OKR)? How do you set and communicate goals and results in your organization? Because you want people to move together in the right direction, you need to get clarity.

KPIs

What are your Key Performance Indicators (KPI)? How do you want to measure value that demonstrates how effectively your company is achieving key business objectives?  Because you want your organization to evaluate its success at reaching targets, you need to get clarity.

Structure

What does the team design or structure of the organization look like on portfolio, program, product, and service layers? We need a shared understanding of which individuals or teams are responsible for what.

Governance

What does the governance of the organization look like? How do we manage our budget, dependencies, risks, or quality? What are the inputs, outputs, and artifacts?

Metrics and Tools

Because we want to manage our system of delivery, what are necessary metrics and tools of the organization?

Get Clarity

Remember, if you expect others to commit to something, regardless if it’s a process or a deliverable, we need a shared understanding.

The post Get Clarity appeared first on LeadingAgile.

Categories: Blogs

Lean Flow: Priority #1 for Lean Executives

Enjoy this excerpt from the Lean Business Report. Learn why Lean executives prioritize Lean flow to improve efficiency, value delivery, and business agility.

The post Lean Flow: Priority #1 for Lean Executives appeared first on Blog | LeanKit.

Categories: Companies

The secret to making people buy your product

Xebia Blog - Tue, 03/07/2017 - 20:21

There is no greater waste than building something extremely efficient, well architectured (is that a word?), with high quality that nobody wants. Yet we see it all the time. We have the Agile manifesto and Scrum probably to thank for that (the seeing bit.) “Our highest priority is to satisfy the customer through early and […]

The post The secret to making people buy your product appeared first on Xebia Blog.

Categories: Companies

Architectural Refactoring

TV Agile - Tue, 03/07/2017 - 17:31
Let’s face it, the system you maintain isn’t meeting expectations. The crystal ball you were issued at engineer academy was broken, and you guessed wrong about how the system would grow. Now, you’re faced with a choice: should you bite the bullet and rewrite, or should you somehow try to salvage what you have? In […]
Categories: Blogs

Agile Architecture Roadmapping

Scrum Expert - Tue, 03/07/2017 - 17:14
In the Agile world, software architecture is about making design decisions with just enough anticipation. Too much anticipation leads to overly heavy architectural constructs that may never be used...

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

Blog Series: TDD and Process Part I

NetObjectives - Tue, 03/07/2017 - 15:58
Part 1: The False Dichotomy Traditions in software testing suggest that the balance among the various types of test types (Acceptance, API, Integration, Unit) should be weighted toward the lower-level, more granular tests and less toward the larger-scale, or end-to-end tests.  The visualization is typically something along these lines, in terms of the effort that should be devoted to each: It...

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

Agile Pixie Dust

NetObjectives - Tue, 03/07/2017 - 13:26
You know the history well. At an executive level, the organization has decided to "go Agile". Everyone in the organization attended a 1/2 day Scrum Training course. The project managers were re-titled as "Scrum Masters" and the business analysts were re-labeled "Product Owners". Finally, the developers and testers were reorganized into a set of Scrum Teams and "Sprint Zero" was started. Since...

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

Agile in Distributed Teams

Growing Agile - Tue, 03/07/2017 - 10:00
We were recently featured on Agile TD Mondays talking about Distributed Teams. Watch the video here:
Categories: Companies

Knowledge Sharing


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