This is a great introduction to Cloud Concepts!Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
Advanced training for leaders, executives and change agents working in Agile environments.
Your success as a leader in an Agile organization requires looking beyond Agile itself. It requires a deep understanding of your organization and your own leadership path. To equip you for this journey, you will gain a strong foundation in understanding organizational culture. From there, you will learn key organization and leadership models that will allow you to understand how your organizational culture really works.
Now you are ready to start the journey! You will learn about organizational growth – how you may foster lasting change in your organization. Key is understanding how it invite change in a complex system. You will also learn about leadership – how you may show up more effectively. And how to help others.Learning Objective(s):
Though each Certified Agile Leadership course varies depending on the instructor, all Certified Agile Leadership courses intend to create awareness of, and begin the journey toward, Agile Leadership.
Graduates will receive the Certified Agile Leadership (CAL 1) designation.
See Scrum Alliance Website for further details.Agenda: Agenda (Training Details)
We create a highly interactive dynamic training environment. Each of you are unique – and so is each training. Although the essentials will be covered in every class, you will be involved in shaping the depth and focus of our time together. Each learning module is treated as a User Story (see photo) and we will co-create a unique learning journey that supports everyone’s needs.
The training will draw from the learning areas identified in the overview diagram.Organizational Culture
“If you do not manage culture, it manages you, and you may not even be aware of the extent to which this is happening.” – Edgar Schein
- Why Culture? Clarify why culture is critical for Organizational Success.
- Laloux Culture Model: Discuss the Laloux culture model that will help us clarify current state and how to understand other organizations/models.
- Agile Culture: Explore how Agile can be seen as a Culture System.
- Agile Adoption & Transformation: Highlight differences between Agile Adoption and Transformation.
- Dimensions of Culture: Look at key aspects of culture from “Reinventing Organizations”. Where are we and where might we go?
- Culture Case Studies: Organizational Design: Explore how leading companies use innovative options to drive cultural operating systems.
- Theory X – Theory Y: Models of human behaviour that are implicit in various types of management systems.
- Management Paradigms: Contrast of Traditional “Modern” Management practices with Knowledge worker paradigm.
- The Virtuous Cycle: Key drivers of success emergent across different high-performance organizational systems.
- Engagement (Gallup): Gallup has 12 proven questions linked to employee engagement. How can we move the needle?
- Advice Process: More effective decision-making using Advice Process. Build leaders. Practice with advice cards.
- Teal Organizations: Explore what Teal Organizations are like.
- Leading Through Culture: How to lead through culture so that innovation and engagement can emerge.
- VAST – Showing up as Leaders: VAST (Vulnerability, Authentic connection, Safety, & Trust) guides us in showing up as more effective leaders.
- Temenos Trust Workshop: Build trust and charter your learning journey. Intro version of 2 day retreat.
- Compassion Workshop: How to Use Compassion to Transform your Effectiveness.
- Transformational Leadership: See how we may “be the change we want to see” in our organizations.
- Leading Through Context: How to lead through context so that innovation and engagement can emerge.
- Leadership in Hierarchy: Hierarchy impedes innovation. Listening and language tips to improve your leadership.
- Working With Culture: Given a Culture Gap. What moves can we make? Work with Culture or Transformation.
- Complex Systems Thinking: Effective change is possible when we use a Complex Systems model. Cynefin. Attractors. Emergent Change.
- Healthy “Agile” Initiatives: How to get to a healthy initiative. How to focus on the real goals of Agile and clarify WHY.
- People-Centric Change: The methods we use to change must be aligned with the culture we hope to foster. How we may change in a way that values people.
- Transformation Case Study: Walkthrough of how a transformation unfolded with a 100 person internal IT group.
The post Announcement: New Leadership Training – First in Canada! appeared first on Agile Advice.
In my last post I attempted to cluster Game of Thrones episodes based on character appearances without much success. After I wrote that post I was flicking through the scikit-learn clustering documentation and noticed the following section which describes some of the weaknesses of the K-means clustering algorithm:
Inertia is not a normalized metric: we just know that lower values are better and zero is optimal.
But in very high-dimensional spaces, Euclidean distances tend to become inflated (this is an instance of the so-called “curse of dimensionality”).
Running a dimensionality reduction algorithm such as PCA prior to k-means clustering can alleviate this problem and speed up the computations.
Each episode has 638 dimensions so this is probably the problem we’re seeing. I actually thought the ‘curse of dimensionality’ referred to the greater than linear increase in computation time; I hadn’t realised it could also impact the clustering itself.
As the documentation notes, the K-Means algorithm calculates euclidean distances to work out which cluster episodes should go in. Episodes in the same cluster should have a small euclidean distance and items in different clusters should have larger ones.
I created a little script to help me understand the curse of dimensionality. I’ve got 4 pairs of vectors, of size 4, 6, 100, and 600. Half of the items in the vector match and the other half differ. I calculate the cosine similarity and euclidean distance for each pair of vectors:
from sklearn.metrics.pairwise import cosine_similarity import numpy as np def distances(a, b): return np.linalg.norm(a-b), cosine_similarity([a, b]) def mixed(n_zeros, n_ones): return np.concatenate((np.repeat(, n_ones), np.repeat(, n_zeros)), axis=0) def ones(n_ones): return np.repeat(, n_ones) print distances(mixed(2, 2), ones(4)) print distances(mixed(3, 3), ones(6)) print distances(mixed(50, 50), ones(100)) print distances(mixed(300, 300), ones(600)) (1.4142135623730951, 0.70710678118654746) (1.7320508075688772, 0.70710678118654768) (7.0710678118654755, 0.70710678118654757) (17.320508075688775, 0.70710678118654746)
The euclidean distance for the 600 item vector is 17x larger than for the one containing 4 items despite having the same similarity score.
Having convinced myself that reducing the dimensionality of the vectors could make a difference I reduced the size of the episodes vectors using the the Truncated SVD algorithm before trying K-means clustering again.
First we reduce the dimensionality of the episodes vectors:
from sklearn.decomposition import TruncatedSVD n_components = 2 reducer = TruncatedSVD(n_components=n_components) reducer.fit(all) new_all = reducer.transform(all) print("%d: Percentage explained: %s\n" % (n_components, reducer.explained_variance_ratio_.sum())) 2: Percentage explained: 0.124579183633
I’m not sure how much I should be reducing the number of dimensions so I thought 2 would an interesting place to start. I’m not sure exactly what the output of the reducer.explained_variance_ratio_ function means so I need to do some more reading to figure out whether it makes sense to carry on with a dimension of 2.
For now though let’s try out the clustering algorithm again and see how it gets on:
from sklearn.cluster import KMeans for n_clusters in range(2, 10): km = KMeans(n_clusters=n_clusters, init='k-means++', max_iter=100, n_init=1) cluster_labels = km.fit_predict(new_all) silhouette_avg = metrics.silhouette_score(new_all, cluster_labels, sample_size=1000) print n_clusters, silhouette_avg 2 0.559681096025 3 0.498456585461 4 0.524704352941 5 0.441580592398 6 0.44703058946 7 0.447895331824 8 0.433698007009 9 0.459874485986
We have a couple of cluster sizes which fit in the ‘reasonable structure’ and a few just on the edge of fitting in that category.
I tried varying the number of dimensions and found that 3 worked reasonably well, but after that the silhouette score dropped rapidly. Once we reach 30 dimensions the silhouette score is almost the same as if we hadn’t reduced dimensionality at all.
I haven’t figured out a good way of visualising the results of my experiments where I vary the dimensions and number of clusters so that’s something to work on next. I find it quite difficult to see what’s going on by just staring at the raw numbers.
I also need to read up on the SVD algorithm to understand when it is/isn’t acceptable to reduce dimensions and how much I should be reducing them by.
Any questions/thoughts/advice do let me know in the comments.
“Leadership is the key to driving change and progress. Executives and managers of Scrum teams need to nurture the environment, let go of the “how”, allow the team to learn from mistakes, and encourage and coach the growth of the collective team knowledge and overall experience.
Understanding the dramatic impact leadership has on a transitioning team is also very critical, as a single word or direction from the executive level can single-handedly affect (either positively or negatively) the team’s future behaviours and resulting successes or failures. And without a true environment of trust built by the leadership, team members will often shy away from taking a risk to try something new or unknown.” (By Senior Agile Coach Jerry Doucett)Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
The post Quotable Quotes: Leadership is the key to driving change appeared first on Agile Advice.
Michael James, Certified Scrum Trainer, shares an article listing his understanding of the key obstacles to Enterprise Agility which can be found in the link on this site. He lists seven obstacles and the most meaningful seems to be number seven, staying committed to the transformation. Each individual on the team must be committed to the transformation, to be willing to endure the “storming period” which a team goes through when they are learning to work together in an agile way.
When they stay committed, as Michael James describes, then they are well on their way to adapting the agile methodologies which will allow for high-performing teams.
Experts in the field will be well aware of this concept by now, but for beginners it is worth breaking down into bits. Every conversation about agility in an organization ultimately involves a whole team changing – and not just one or two members by the way — so that an entirely new and more productive environment can allow for more efficient delivery of product.
Have you seen an agile team go through storming? What was it like? Did you see positives come out of it? Please describe your experiences here.
Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
- Sponsored: 64% off Code Black Drone with HD Camera
Our #1 Best-Selling Drone--Meet the Dark Night of the Sky!
Having a good process is only part of the equation. A good Scrum Master will champion and enforce that process, protect the team, encourage collaboration, highlight (escalate when necessary) and encourage the removal of obstacles, facilitate discussions, provide fair and constructive feedback, cultivate a culture of continuous improvement and learning, and work to help the team live the Agile values.
Remember that the Scrum Master has authority over the process but not over the team. As the process champion the Scrum Master may sometimes even find themselves in a conflict between maintaining the Scrum rules and guiding the team as they discover the need to adapt practices to better align with their own needs and ways of working. In that regard a Scrum Master should understand and embrace the servant leader role. In the end, a Scrum Master needs to be the person that helps the team make decisions, but not the person that makes decisions for them. (By Senior Agile Coach Jerry Doucett)Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
The post Quotable Quote: Scrum Master has authority over the process but not over the team appeared first on Agile Advice.
Ben Yehoolda, author of two excellent articles on LinkedIn’s Pulse, has recently connected with BERTEIG and I am happy to share these insightful pieces which offer steps to success for software development teams.The first one, Software Development Team Composition, offers a cost-effective strategy for having a high-performing team without high costs. He writes, “Rather than building a costly team made up of only the best, the leading parameter which should dictate team composition is the complexity of the work. For the average software project the bulk of the work could be handled quite well by a B (or intermediate) level developer. The more complex work (design patterns, architecture changes, frameworks research) constitute a smaller portion of time but would definitely require an A (or Senior) level developer. To make the best use of your development budget, you should keep in mind that every development project has some very simple yet time consuming work which could be done be a C (or Junior), such as; code clean up, commenting, adding disclaimers, building unit test and small GUI alignments.” In the second article, Steps to Building a Software Team, he writes about three steps to keep a software team engaged. This statement caught my attention. He writes, “The challenging wizardry-like act of leading a development team requires knowing more about the tools and craft of software development than the other team members. At the same time, every good leader should have the drive and charisma of a top-tier sales person to motivate the team. These two sets of skills can be hard to find in the same person. If you’re struggling to find an external candidate with these qualifications, consider looking within the team to promote or expand the responsibilities of an existing employee. Keep in mind, however, leadership training to a senior developer might work better than technology training to junior managers.” These are great considerations for software development teams. Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
In my last post I showed how to find similar Game of Thrones episodes based on the characters that appear in different episodes. This allowed us to find similar episodes on an episode by episode basis, but I was curious whether there were groups of similar episodes that we could identify.
scikit-learn provides several clustering algorithms that can run over our episode vectors and hopefully find clusters of similar episodes. A clustering algorithm groups similar documents together, where similarity is based on calculating a ‘distance’ between documents. Documents separated by a small distance would be in the same cluster, whereas if there’s a large distance between episodes then they’d probably be in different clusters.
The simplest variant is K-means clustering:
The KMeans algorithm clusters data by trying to separate samples in n groups of equal variance, minimizing a criterion known as the inertia or within-cluster sum-of-squares. This algorithm requires the number of clusters to be specified.
The output from the algorithm is a list of labels which correspond to the cluster assigned to each episode.
Let’s give it a try on the Game of Thrones episodes. We’ll start from the 2 dimensional array of episodes/character appearances that we created in the previous post.
>>> all.shape (60, 638) >>> all array([[0, 0, 0, ..., 0, 0, 0], [0, 0, 0, ..., 0, 0, 0], [0, 0, 0, ..., 0, 0, 0], ..., [0, 0, 0, ..., 0, 0, 0], [0, 0, 0, ..., 0, 0, 0], [0, 0, 0, ..., 0, 0, 0]])
We have a 60 (episodes) x 638 (characters) array which we can now plug into the K-means clustering algorithm:
>>> from sklearn.cluster import KMeans >>> n_clusters = 3 >>> km = KMeans(n_clusters=n_clusters, init='k-means++', max_iter=100, n_init=1) >>> cluster_labels = km.fit_predict(all) >>> cluster_labels array([1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 1, 1, 0, 0, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2, 2, 2, 2, 2, 2, 2, 2, 0, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2], dtype=int32)
cluster_labels is an array containing a label for each episode in the all array. The spread of these labels is as follows:
>>> import numpy as np >>> np.bincount(cluster_labels) array([19, 12, 29])
i.e. 19 episodes in cluster 0, 12 in cluster 1, and 29 in cluster 2.How do we know if the clustering is any good?
Ideally we’d have some labelled training data which we could compare our labels against, but since we don’t we can measure the effectiveness of our clustering by calculating inter-centroidal separation and intra-cluster variance.
i.e. how close are the episodes to other episodes in the same cluster vs how close are they to episodes in the closest different cluster.
scikit-learn gives us a function that we can use to calculate this score – the silhouette coefficient.
The output of this function is a score between -1 and 1.
- A score of 1 means that our clustering has worked well and a document is far away from the boundary of another cluster.
- A score of -1 means that our document should have been placed in another cluster.
- A score of 0 means that the document is very close to the decision boundary between two clusters.
I tried calculating this coefficient for some different values of K. This is what I found:
from sklearn import metrics for n_clusters in range(2, 10): km = KMeans(n_clusters=n_clusters, init='k-means++', max_iter=100, n_init=1) cluster_labels = km.fit_predict(all) silhouette_avg = metrics.silhouette_score(all, cluster_labels, sample_size=1000) sample_silhouette_values = metrics.silhouette_samples(all, cluster_labels) print n_clusters, silhouette_avg 2 0.0798610142955 3 0.0648416081725 4 0.0390877994786 5 0.020165277756 6 0.030557856406 7 0.0389677156458 8 0.0590721834989 9 0.0466170527996
The best score we manage here is 0.07 when we set the number of clusters to 2. Even our highest score is much lower than the lowest score on the documentation page!
I tried it out with some higher values of K but only saw a score over 0.5 once I put the number of clusters to 40 which would mean 1 or 2 episodes per cluster at most.
At the moment our episode arrays contain 638 elements so they’re too long to visualise on a 2D silhouette plot. We’d need to apply a dimensionality reduction algorithm before doing that.
In summary it looks like character co-occurrence isn’t a good way to cluster episodes. I’m curious what would happen if we flip the array on its head and try and cluster the characters instead, but that’s for another day.
If anyone spots anything that I’ve missed when reading the output of the algorithm let me know in the comments. I’m just learning by experimentation at the moment.
I was (wo)manning the Berteig booth for most of this day-long event with my colleague Nima Honarmandan, since we were one of the Open Agile Conference sponsors. Still, I was able to nip away and take in a seminar called “Value: From Meh to Wow” delivered by Mike Edwards, author of leadingforchange.ca
After a personal introductory story about his dog dying while he was away from home, and WestJet Corporation’s remarkable assistance to him to get home as soon as possible, he listed three kinds of value: that which is monetized, that which is frugal and that which has a wow factor.
He believes WestJet has the wow factor because people are not just numbers or resources to them – people are truly people. He said that the employees of WestJet are empowered to act as if they’re owners, and so can make important (and compassionate) decisions for people on a case by case basis.
Edwards feels companies need to know what their customers’ values are, and allow themselves to align with them. Companies cannot hope to “wow” people with freebies. His point was that to create a wow factor in one’s business one needs to focus on relationships.
In an exercise, he had attendees make 3 columns on a sheet of paper. The first column was to list our employers’ values, the second to list our own values, and the third to list our customers’ values. I was “wowed” to see that, as regards my own employment and our customers, there was a great degree of alignment between all three groups, valuing such things as learning, honesty, encouragement, responsiveness and agility.
As for most of my day in the stands (at the Berteig booth), I observed that agilists (practitioners of Agile) are, by and large, very caring and user-friendly people. Between seminar sessions, hundred of them flowed through the hallways. Many of them greeted each other like long-lost buddies with big hugs, many engaged in in-depth conversations, and most were joyful and energetic.
As my colleague Nima and I met people at our booth, responded to questions, and handed out packs of Estimation Cards (freebies are fun at an event like this), I mused on the blessing of human contact. As wisdom would have it, there is a time for all aspects of life: to work, to learn, to rest, and a time to enjoy the diversity of our human family.Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
The post A View From the Stands: Open Agile Conference, Toronto 2015 appeared first on Agile Advice.
As you can probably imagine, we are quite relieved to have finally published the SAFe 4.0 Reference Guide. But after our five-minute celebration we went right back to work on some other projects, one of which is another SAFe book that Richard and I are collaborating on. The work has revealed some room for improvement on the SAFe Lean-Agile Principles articles, so I’m now in the process of getting those updated. They aren’t long, but distilling the nine most valuable principles into these short articles isn’t a trivial effort either.
I’ve largely completed that work, and in the interest of accelerating value delivery, I’ve already pushed two of them to the site. Specifically, Principle 2: Apply Systems Thinking, and Principle 9: Decentralize Decision-making. These aren’t dramatically different conceptually, but they are a little deeper, a little better written, and hopefully, a little more valuable.
—Dean and the Framework team
One of the -ilities people try to build into their software is maintainability. It’s been that way for as long as I can remember (although as I grow older, my memory grows shorter).
As the pace of change continues to increase, the necessity for IT organizations to be able to deliver on demand also increases. We’re on the look-out for anything that can enable this: continuous integration, heavy test automation, Behavior-Driven Development, DevOps, automated deployment, resilient infrastructures that can adjust dynamically to changing workloads or server outages, reactive architectures that flex under user demand.
A maintainable application may not be up to these challenges. The idea of “maintainability” implies that the application is a long-term artifact; a cathedral or a Great Pyramid. But keeping up with the demand for change may call for something a little different: Applications that can be discarded and replaced rapidly with no negative impact to customers, low risk, and low cost.
The situation calls for a new -ility: Replaceability.
Your first reaction may be, “We can’t do that.” You’re right. You can’t do that today. The appropriate question to ask when we want to do something that we can’t do today is this:
What would have to be true that is not true now in order to enable the New Thing?Strategic and Tactical Assets
The first prerequisite that I can see is we must explicitly decide which applications are tactical and which are strategic. I think the idea of replaceability pertains to tactical assets, and not strategic ones.
If you have a well-designed SOA environment, you can start by assuming most of the applications in the “core” are strategic and most of the applications that interact with core assets through the service layer are tactical.
Most organizations don’t have a well-designed SOA environment. How can we begin if we don’t have that advantage? I think we can consider what types of IT assets are central to our business operation.
Here’s a suggested taxonomy, for discussion purposes.
- Data-centric operations
- Transaction-centric operations
An organization for which data is central to operations is data-centric. I will suggest these types of businesses, for starters:
- an advisory company for investors
- a company that collects information about vehicle histories
An organization for which high-volume, fast transaction processing is central to operations is transaction-centric. I will suggest these types of businesses:
- a social media service
- a mass marketing company
An obvious objection arises to this taxonomy: All these types of businesses are centered on data in one way or another. Clearly, the investment advisory company collects and analyzes data about stocks, and the vehicle history company collects data about events in the lives of vehicles. But the social media company and mass marketing companies are in the data business, as well. The former sells information about users and their preferences, and the mass marketing company depends on scrubbed mailing lists or phone lists to maximize the response rate of mass marketing campaigns. Aren’t they all data-centric businesses?
The key as I see it is to look at the question from the perspective of IT operations. In the first two cases, the collection of data is critically important. It has to be clean, consistent, accurate, and readily accessible. Tactical applications are like windows into the data, and clients of the algorithms that make sense of the data. The data and the algorithms are the strategic assets in that case.
In the cases of the social media service and the mass marketing firm, there can be a great deal of noise in the data without affecting the business negatively. It’s more critical that they can process a very large number of transactions quickly. They don’t even require an ACID database. Dirty reads are okay. Updates that catch up “eventually” are okay. But the transaction processing has to be absolutely rock-solid.
Another difference pertains to the “stickiness” of the data. The investment advisor and the vehicle history reporter need to keep long-term historical data intact. The longer the history, the better the information they can report to their customers.
The social media service and the mass marketer don’t need to keep information about customer preferences or customer addresses and phone numbers for the long term. Those categories of information tend to be transient. People’s tastes change over time as they go through different stages of life. People relocate and change phone numbers from time to time. And it’s easy enough to start over; certainly not the same impact as for the performance history of an investment instrument.Considerations for Strategic Assets
Once we’ve determined which IT assets are strategic and which are tactical, we can apply appropriate considerations to the selection and support of each type.
In my view, the following considerations apply to strategic assets:
- Vendor relationship: Partner
- Key product selection criteria: Unique features of a particular product
- Budget for support: High
- Cost of replacement: High
The new -ility, replaceability, doesn’t apply to strategic assets. We will intentionally lock ourselves into a specific product because of the special features it offers that help support our business needs. We won’t relate to the vendor as a customer, but rather we will establish a partnership arrangement with them. We need close and immediate support for anything and everything pertaining to our strategic assets. To get that, we’ll budget more to support these assets than we will to support tactical ones. We’ll also accept the fact that should the need arise to replace a strategic asset, doing so will involve significant effort and cost. We don’t plan to change strategic assets frequently.
An aside: What’s the implication for Agile development? Changes in strategic assets will tend to be characterized by low uncertainty, low time-to-market pressure, and a need for significant up-front analysis and planning. This is not the sweet spot for conventional Agile methods.
What does it mean to replace a tactical asset? For the investment advisory firm, the data and the analysis algorithms are strategic assets. Web-based or mobile clients are merely “windows” into those assets. These client applications should be replaceable quickly at low cost and with low risk. Replacing, say, a .NET webapp with a Ruby webapp should have zero impact on the central data store or on the code that performs investment analysis.Considerations for Tactical Assets
In my view, the following considerations apply to tactical assets:
- Vendor relationship: Customer/supplier
- Key product selection criteria: Adherence to vendor-neutral standards
- Budget for support: Low to moderate
- Cost of replacement: Low
This is the area in which replaceability becomes a critical success factor for the enterprise.
Although most organizations lack a well-defined SOA infrastructure, each tactical application will have some way of interacting with strategic assets. In an established organization there will almost always be a range of different methods: point-to-point interfaces, file-sharing, SOAP services, RESTful services, RPC, cross-memory services…you name it. This model doesn’t depend on any particular technical implementation. Old technologies fit into the model the same way as newer ones.
The key point is we don’t want any baked-in dependencies on product-specific features above and beyond “plain vanilla” support for vendor-neutral standards. We expect to replace these applications from time to time, and when we do so we don’t want to hit a wall of technical issues. A web server is a web server; a rules engine is a rules engine; a SQL database is a SQL database. We don’t want to configure tactical assets in a way that will add cost or delay to their replacement.
An aside: What’s the implication for Agile development? Changes to (or replacement of) tactical assets will tend to be characterized by high time-to-market pressure and high means uncertainty, even if not by high-end uncertainty. This is the sweet spot for adaptive approaches such as Agile development.
What does it mean to replace a tactical asset? Let’s say the social media service grows from 100 million users to 1 billion users, and the document database they were using is no longer providing the transaction times they require. They want to switch to a graph database or a relational database. They need to be able to do this with a minimum of hassle. They will have to reformat the data; hopefully, that can be done with a script. But there are always “gotchas.” Our goal is to keep everything as simple as we can on the tactical level, to minimize the number and difficulty of the inevitable “gotchas.”Enabler 1: Specification by Example / Behavior-Driven Development
You might argue that we’ve tried to replace applications in the past, and it was always a hassle. How many “it’s just a rewrite” projects have we lived through? I’ve lost count. I guess you have, too.
We need a practical way to be sure we haven’t overlooked some important feature when we replace a tactical application. As far as I know, there’s no magical way to do this. However, there is a technology that offers a pretty good partial solution: The text-based “language” known as Gherkin.
Gherkin is a specification for formatted text that is designed to support Specification by Example or Behavior-Driven Development. The interesting thing about Gherkin for purposes of replacing a tactical application is that it is technology-agnostic. The only thing you would ever have to change when moving Gherkin specifications from one platform to another is the line endings, if you were moving to or from Microsoft Windows. Any Gherkin interpreter on any platform can process standard Gherkin text files.
Gherkin won’t help if we’re replacing one database management system with another, but in that sort of replacement we don’t have the concern about overlooking a functional requirement. Gherkin can help with replacing a “window” application that accesses strategic assets. The user-observable behavior of the application can be captured in the form of Gherkin scenarios, which can then be used to ensure the new application supports the same functionality as the old one.
There’s no real cost involved in using Specification by Example or Behavior-Driven Development. These techniques are merely a question of self-discipline on the part of technical professionals. Gherkin interpreters for just about any platform and any programming language are free downloads. The value of these practices extends not only to clarity about requirements, automated functional checking, and dependable documentation, but also helps support the idea of replaceability for tactical applications.
Therefore, one way to help prepare the ground for separating strategic and tactical assets is to back-fill functional specifications for existing applications in Gherkin. This can be done incrementally over time.Enabler 2: Separation of Concerns
In working with legacy applications, we need to pay attention to separation of concerns. In particular, the code that communicates across the “boundary” between the strategic and tactical worlds has to be loosely coupled with the rest of the application code. This applies both to strategic applications and tactical ones.
Consider the case when a social media service wants to replace the database management system. The strategic transaction-processing code should not be affected by this change. The only parts of that code that should be affected are the layers or components that directly interact with the database. Strategic functionality must be unaware of any changes to the database implementation.
Therefore, one way to help prepare the ground for separating strategic and tactical assets is to refactor legacy applications to ensure clean separation of concerns. This can be done incrementally over time.Summary
To meet emerging demands for rapid change, IT organizations need to consider ways to enable very fast replacement of technical assets that are liable to be affected by changes in the market or in business direction. By separating strategic and tactical IT assets, we can take steps to ensure it will be easy, fast, and cheap to replace tactical assets, while still enjoying the benefits of tight integration with the special features of strategic products that support our business operations. Thinking about IT assets in this way helps us understand where to focus our budget and effort to achieve maximum value with minimal overhead.
Is Agility limited to software? Ron Jeffries (l) and Steve Denning at Agile 2016
Photo thx to Steve Denning Steve Denning has collected the evidence and laid out the case that Agile is not limited to software, nor is it merely a process, nor is it something you can do with part of your time, nor is it something you can have your staff do. Agile is a mindset, and this mindset is applicable to many if not all fields of endeavor.1 At the same, he questions whether the mindset is actually defined in the Agile Manifesto.2
What is this mindset? Where does it come from? How do you know that you or your company has it? And is it really missing from the Agile Manifesto?
There is no question that Steve is correct in his assertion that Agile is a mindset. Practitioners have known this since the beginning. I remember my first interview, back in 2008 or so, for employment at an Agile consulting company. The mindset question was my interview partner's key question, and I couldn't explain it. (No, I didn't get the job.) In 2009, I opened the first Lean Agile Scrum Conference in Zurich with the thought, “In 2001, we started uncovering better ways of developing software. Since then, we have uncovered the need for better ways to lead organizations.”
More recently, the importance of the Agile mindset was the key finding of the Scrum Alliance Learning Consortium:
“A universal feature of all the site visits was a recognition that achieving these benefits [of Agile values and practices] is dependent on the requisite leadership mindset. Where the management practices and methodologies were implemented without the requisite mindset, no benefits were observed.... What is new is the way that the new management goals, practices, and values constitute a coherent and integrated system, driven by and lubricated with a common leadership mindset.”
Denning, Goldstein and Pacanowsky. 2015 Report of the Learning Consortium I believe The Manifesto for Agile Software Development (“the Agile Manifesto”) does define a mindset. This mindset leads you to the 4 values, 12 principles, and uncounted practices that are helpful in software development. This mindset also leads you to the five shifts of Radical Management, which are much more generally applicable.
Agility starts in the headIf Agility is mindset, then it starts in the head. It starts in the head of each individual. It starts in the head of the company, i.e. its leadership team, and it starts in the heads of the individuals that make up the leadership team.
I believe that you can assess the Agility of an organization through five simple questions, all derived from the Agile Manifesto, even if they are not primarily developing software. You can ask these questions to their leadership, and you can get confirmation from by asking their staff or customers the same questions.
Let's look at how the Agile Manifesto defines the mindset, then derive a set of questions based on that mindset. Let's take the case of a hypothetical railway: How would a railway apply the Agile Manifesto? How could an organization that values operational goals, like having the trains run on time, be Agile as well?
The most neglected part of the Agile Manifesto?Quickly! What is the first sentence of the Agile Manifesto? If you said something about “people and interactions over tools and processes,” you got the wrong answer! But don't feel bad. At the last Scrum Gathering in Bangalore, I asked 5 Scrum trainers the same question, and only one of them got the right answer! Here are the first sentences of the Agile Manifesto:
“We are uncovering better ways of developing software, by doing it and helping others to do it. Through this work we have come to value…”How come no one talks about the first sentence? It carries so many messages! For example:
- We are doing. It's not about software quality, it's about uncovering better ways to develop software. It's about the process and not the result.
- We don’t have the best practices, we are constantly looking for better practices. We are open to the possibility that someone else has a better idea.
- We expect to be better tomorrow than we are today, so we maintain a certain humility about our knowledge today.
- We are helping others to do the same. Not teaching, helping! Sharing knowledge, especially beyond the borders of our own organization, enables our own learning, enables us to learn from others, and builds overall knowledge faster. This clause defines our relationship to other people and organizations.
We are uncovering better ways of doing what we do, by doing it and helping others to do the same. The first question is, what exactly does our train system do? Run trains? Transport people and goods throughout the country? Something else? They might try this one on for size:
We are uncovering better ways of running the trains on time, by doing it and helping others to do the same...What if our rail system incorporated this statement in its mission? How would that railway be different than the ones we know today? Simon Synek, in his famous work Start with why, gives us a clue:
“One by one, the German luxury car makers begrudgingly added cup holders to their fine automobiles. It was a feature that mattered a great deal to commuter-minded Americans, but was rarely mentioned in any research about what factors influenced purchase decisions.”For context, Chrysler introduced modern cup holders with the Chrysler Voyager back in 1983o3. My 1993 BMW 3-Series did not have them. My 2001 BMW 5 Series had pretty flimsy cupholders, and my wife's 2011 BMW 5 Series finally has pretty good cup holders.
What was missing here? A culture of learning, particularly of learning from outside the organization. An Agile organization is a learning organization. An Agile organization will be looking for, validating and embracing new ideas quickly, so that they can get better at doing what they do.
What does it mean to have an “Agile Mindset?” At the very least, someone who has the mindset is in alignment with the first sentence of the Agile Manifesto: We are uncovering better ways of doing what we do, by doing it, and helping others to do the same.
The first question: What do you do? What does your organization do for its customers or stakeholders? The answer must contain a verb, and should represent something of value to your customers or stakeholders. So making money is not what you do. It is a result of what you do.
Even the choice of mission says something about what the organization values, which may in turn determine its ability to meet the challenges of the 21st century. If our train system just wants to run the trains on time, how capable will it be to respond to new market challenges like digitalization (Uber, Zipcar, Mobility) or technological advancement (electric cars, self-driving cars)?
The second and third questions:
Uncovering better ways of doing thingsAre you uncovering better ways of doing what you do, by doing it? This is about your culture of change and improvement. If you prefer the status quo, you are unlikely to be uncovering better ways of doing what you do.
Are you uncovering better ways of doing what you do, by helping others to do the same? “Helping” is a peer-to-peer activity, not a top down activity. So this not about getting training for your staff, this is about advancing the state of your art, having time to improve skills and technology, and learning and sharing beyond your own four walls.
What do you value?The Agile Manifesto defines 4 value pairs:
“Through this work we have come to value:
Individuals and interactions over processes and tools
[Customer visible value] over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.”As above, I have replaced “Working Software” with “Customer visible value” to make it a bit more general. The first of the twelve principles are:
- Our highest priority is to satisfy the customer through early and continuous delivery of [Customer visible value].
- Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
By putting valuable things in relationship to one another, Agile values become a tool to guide decision making, which in turn enables more distributed decision making.
Must an organization embrace these values to be an Agile organization? This is a harder question, because context can be very different. What would an Agile police force or military unit choose to value? What would our hypothetical train system value?
As a frequent user of the Zurich public transportation system, I believe that they want to provide a high level of service to their customers, defined as on-time performance, frequent connections, ease of use, and comfort. But if they catch you without ticket, they have no mercy, and they don't care about your reasons!
Ensuring compliance with ticketing rules or showing compassion to loyal customers? How would our Agile train system decide this case? Would they want to handle it differently? Answering this question requires thought, and who is best positioned to make this decisions? The people who understand the problem best.
What other conflicting values might our train system choose to evaluate? For example:
- An easy-to-remember time table or having enough seats for all passengers?
- Trains departing on time or passengers making their connections when their train is late?
- Minimizing operating costs or having a train available frequently and regularly?
- Ensuring compliance with ticketing rules or showing compassion to loyal customers?
Questions 4 and 5: What do you value?Have you reflected on the values and principles of the Agile Manifesto and what they mean for you? Can you concisely explain your values and why you value them?
What do your staff and customers think?It may be possible to kid yourselves, but kidding your customers and staff is much harder. So ask yourself:
- On a scale of 0 to 10 (highly unlikely to highly likely), how likely are your customers or staff to describe your company as an Agile organization?
Peter's 5 Question AssessmentIf you can concisely answer the first question and answer yes to the remaining questions, then I believe you can say you have an Agile mindset. If your company and its leadership can answer yes to these same questions, then I believe you can claim that your company is an Agile organization:
- What do you do (besides make money)?
- Are you uncovering better ways of doing what you do, by doing it?
- Are you uncovering better ways of doing what you do, by helping others to do the same?
- Have you reflected on the values and principles of the Agile Manifesto and what they mean for you?
- Can you concisely explain your values and why you value them?
- On a scale of 0 to 10 (highly unlikely to highly likely), how likely are your customers, stakeholders, or staff to describe you as being Agile?
I have created a one page questionnaire which you can use to conduct this assessment. You can download it both in source from (LibreOffice) and as a PDF. I call it release candidate one, because it is a work in progress. Feel free to try it out, and please send me suggestions, improvements, and data!
1 What is Agile?
2 What's missing in the Agile Manifesto?
3 The History of the Car Cup Holder
- Sponsored: 64% off Code Black Drone with HD Camera
Our #1 Best-Selling Drone--Meet the Dark Night of the Sky!
Your Product Owner needs to be informed, available, business-savvy, knowledgeable, collaborative, and empowered to make decisions about what to build and what order to do it in. They also need to be a strong negotiator and very capable at conducting business driven trade-offs. In the end, a Product Owner needs to effectively communicate, convey and deliver on a clear vision to the Team and Stakeholders to ensure a useful solution is created. Without empowerment, knowledge, and vision in a Product Owner the team will struggle. (By Senior Agile Coach Jerry Doucett)Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
The post Quotable Quote: Without empowerment, knowledge and vision in a Product Owner the team will struggle appeared first on Agile Advice.
Scrum team members should be allocated to as few different initiatives as realistically possible. The more projects you are allocated to, the more task switching you may have to perform, the longer it will take to complete any one item, the thinner you will be spread and the less effective you will be. In other words, people (and teams) should limit their work in progress as much as possible and focus on completing those things that truly matter most. This is true for any framework, but it is particularly emphasized with Agile ones. Note there is a slight but fundamental difference between being allocatedto a team and being dedicated to a team – that is a topic for a future article.
(By Senior Agile Coach Jerry Doucett)
Jerry is leading a series of SAFe training classes in Toronto, Ontario from September through to December 2016. See here for more details.Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
The post Quotable Quotes: Limit Work-In-Progress As Much As Possible! appeared first on Agile Advice.
On May 03, 2016 wildfires encompassing Fort McMurray, Alberta forced the evacuation of more than 88,000 residents, including many friends, family and associates of BERTEIG.
Photo Credit: Wikipedia
One such resident was Garry Berteig, a co-founder of OpenAgile, and long-time resident of Fort McMurray.
Recently, I had the opportunity to speak with Garry from his home in northern Alberta. He presents some meaningful insights into how living and working with an agile mindset helped him and his family move through the disaster with stability. The following articles shares, in his words, some highlights of his experience during and after the event.BEING AGILE IN A CRISIS
By Senior Agile Coach Garry Berteig
Most of the time, when you are acting with agility you are sort of ready for change or turn in direction anyhow. You know what you have to do so your tasks are already in motion, your tasks are already moving towards “done”, not that you have your suitcase packed already but you already know what is the most important thing.
It’s the same for corporations. It’s just not so direct or life-threatening as this catastrophe was but for some companies catastrophe is a slow burn.
The actuality about what occurred, was quite different than the media reports. The media reports were at best simple, at worst a high-level notion.
Yes there was a line of cars, and they show a line up of cars [in the news] but it doesn’t tell you that some people were in one way or another in a state of calm because they are used to being involved in safety measure. That group was relatively calm.
There’s another set of people who were actually terrified and not able to be rational so they have to be handled carefully.
Then another group of people who were on the opposite extreme were kind of ‘having a good time.’ It was taking them away from their normal routines so they were making light of the whole situation. They were rolling windows down, playing loud music, giving peace-signs, stuff like that.
The real take-home point, having landed in Edmonton and being involved with people here is that the kindness, hospitality, generousity and sympathy that people revealed was amazing.
This is a feature that I share and have been sharing with other people who have also found the same thing. It’s been quite remarkable. Their private lives had an opportunity present itself openly. In my opinion, it represents a spiritual condition. Usually people hold that in to themselves and have no opportunity to express that. [They want to be kind, generous and helpful but keep it internalized.]
The government and non-profits have also been incredibly efficient and helpful. Because of all the other experiences with other catastrophes, their quick response to 90,000 people leaving Fort McMurray was remarkable. Within one week they had arranged for financial support for all those people. That to me is the material future of Canada. It is positive. The material and spiritual future of Canada is very great. And that is what I’ve seen here.
The other point is that before Fort McMurray was black-listed by the media but that has turned 180 degrees. Now people will realize the participation in this city from all over the country. The nation raised 1 million through the Red Cross.
Thankfully, not only is Garry and his family safe and well but all other friends and associates are also settling back into their routines and beginning the long journey ahead of restoration and recovery.
UPDATE: August 03, 2016 – Unbelievably, epic flooding has now hit Fort McMurray, and in places the flood waters are damaging houses which had survived the fire. More updates will be shared as they emerge. Garry’s family is still doing well.
Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
The post Interview: Garry Berteig Reflects on Being Agile In a Crisis appeared first on Agile Advice.
We reduced the time to take an idea to production, and our time-to-value has gone down using the SAFe® process. If reaching production would normally take 1½ years, now it could be eight months with the new processes and approach.
—Hrishikesh Karekar, Lead Agile Coach
Our latest case study comes to us from the Israel office of global IT powerhouse, Amdocs, where a team applied some creative tactics to take Agile successfully from theory to a successful rollout.
Amdocs selected SAFe because they needed to roll out Agile practices quickly at various levels of the organization, and the Framework provided the most robust guidance. Unlike previous efforts at applying Agile methods, this time the company followed SAFe best practices closely, and relied on SAFe-certified Agile coaches to guide the execution.
What’s cool about this implementation was the team’s use of gamification to increase adoption at the Team level. They created a game that required teams to check Scrum items off a list, with teams earning points based on how quickly they finished their checklists. As teams completed their tasks, they took selfies and posted them on physical boards with their marked checklists. The game drove deeper understanding of the new process and more discipline in adhering to it.
This all resulted in some impressive outcomes that proved to the team that Agile is no longer theory at Amdocs:
- Shortened time from idea to production from 1.5 years to 8 months
- More frequent deliveries to production
- 30% faster delivery for user acceptance testing
- Demos every 2 weeks to 2 months, instead of 4 months
- System stabilization time down from 6 weeks to less than a week
Most importantly, customers noticed and commented, inspiring the organizations to run more initiatives through SAFe, and management to encourage a company-wide rollout of the Framework.
You can link to the full case study here to get the rest of the story.
Agile methoden zoals Scrum leggen de nadruk op functionaliteit. Klanten verwachten echter naast functionaliteit dat ook de kwaliteit van het product in orde is. Waar Agile voornamelijk aandacht geeft aan het software team en de interactie met de omgeving, kijkt Lean naar de gehele keten: van klantbehoefte tot waarde voor de klant. Een van de aspecten van Lean Software Ontwikkeling is het integreren van kwaliteit.
Lean Software Ontwikkeling combineert Agile en Lean met de volgende 7 principes:
- Verminder Verspillingen (Eliminate Waste)
- Integreer Kwaliteit (Build Quality In)
- Leer Voortdurend (Learn Constantly)
- Lever Snel (Deliver Fast)
- Betrek Iedereen (Engage Everyone)
- Verbeter Continue (Keep getting Better)
- Optimaliseer het Geheel (Optimize the whole)
Retrospectives Exercises Toolbox - Design your own valuable Retrospectives
Mijn definitie van kwaliteit (zie Hoe zorg je met Scrum voor Kwaliteitsproducten en Diensten) is:
Kwaliteit is de mate waarin voldaan wordt aan de behoeften van de gebruikers, en aan de eisen van de opdrachtgevers. Dat kunnen zowel functionele behoeften zijn (iets wat het product of dienst moet doen), of “performance”of niet-functionele eisen (hoe snel, hoe veel, de betrouwbaarheid, etc), vaak is het een combinatie van beide.
Het zijn je klanten die bepalen wat kwaliteit is (en wat niet), en wat vereist is voor een goede kwaliteit. Pas als je weet wat je klanten nodig hebben kun je naar goed oplossingen zoeken om aan hun wensen te voldoen. Je integreert daarmee kwaliteit in het gehele ontwikkelproces. Het juiste product
Hoe kom je erachter wat de klant nodig heeft? Agile kent diverse practices waarin het team en de klanten (in de Scrum praat men over product owner ipv klant) intensief samenwerken om ervoor te zorgen dat het juiste product geleverd wordt. Voorbeelden daarvan zijn de planning game en de product demonstratie.
In de planning game gaat het erom dat de product eisen duidelijker worden. Wat willen klanten bereiken met het product, welke waarde moet het hun gaan bieden? Wat moet het product doen om die waarde te kunnen leveren? Maar ook de kwaliteitseisen: hoe snel moet het werken, en hoe betrouwbaar en stabiel moet het zijn? Het team benut zijn kennis en ervaring om te bepalen wat mogelijk is, en hoe het product op een Lean manier ontwikkelt kan worden.
In de product demonstratie laat je het product zien aan de klanten en vraag om je feedback. Is dit wat de klant wil? Is het goed genoeg? Maar ook: Is het snel genoeg, handig te gebruiken. Betrouwbaar en veilig? En, gegeven wat het product nu doet, wat is er nog meer nodig? Kwaliteit met Agile en Lean
Hoe gaat dat in de praktijk? Laten we kijken naar een medisch systeem wat specialisten gebruiken om onderzoek te doen met patiënten. De specialisten (klanten) willen een aantal mogelijkheden hebben om data en scans van een patiënt te bekijken. Ze willen beelden van eerdere scans kunnen oproepen, inzoomen, en vergelijken. Omdat ze dat vaak met de patiënt erbij doen moet dat snel gaan, en eenvoudig te bedienen zijn. De gegevens mogen niet fout zijn, de specialisten gebruiken ze om beslissingen te nemen waar het leven van de patiënt van af kan hangen.
In de discussies vooraf en in de planning game formuleren de product owner en het team de acceptatie criteria. Voor kwaliteitseisen moeten die criteria meetbaar zijn. Dus niet “snel genoeg” maar “in 90% van de gevallen reageert het systeem binnen 1 seconde”.
Samen met de product owner formuleren de teamleden user stories. De acceptatiecriteria in de user stories worden door het team gebruikt om af te spreken hoe ze de software gaan maken en verifiëren.
Bijvoorbeeld, voor een bepaalde user story doen ze een spike, ze maken een stukje sofware en een testcase die meet hoe snel de software is om te bepalen of wat de klant wil haalbaar is. Voor een andere user story wil het team pair programming gebruiken, het is een complexe functie waarmee de team leden nog geen ervaring hebben.
Er zijn ook stories waarbij test driven design volgens het team de beste aanpak is, en een enkele story waarbij de klant nog niet echt weet wat het product precies moet gaan doen om er op een handige manier mee te kunnen werken, daar lijkt prototyping met Lean Startup het beste te passen.
De vereiste functionaliteit en kwaliteit is bepalend voor de aanpak. De product owner maakt duidelijk wat er nodig is en welke kwaliteit de klanten verwachten. Het team weet wat met een bepaalde manier van werken haalbaar is, en check in de planning game met de product owner. Te weinig kwaliteit is niet goed, maar teveel ook niet. Het gaat bij lean om het vinden van de juiste balans tussen tijd, geld en kwaliteit voor het leveren van functionaliteit.
In de demonstratie wordt de software getoond en gechecked of het voldoet. Daarbij telt zowel de functionaliteit als de kwaliteit. Het moet niet alleen werken, het moet ook snel genoeg zijn, betrouwbaar, bedienbaar, etc. Pas dan voldoet het product aan alle eisen en is het af.
De kracht zit in de samenwerking tussen het team en de product owner gedurende de ontwikkeling. Is er een gedeeld beeld wanneer, hoe en waarvoor klanten het product gebruiken? Wat betekent het product voor hun en welke waarde het kan toevoegen? Kan de product owner voldoende duidelijk maken wat nodig is, en checken de teamleden of ze het goed begrepen hebben? Leren ze van dingen die niet goed zijn gegaan? Integreer kwaliteit
Lean en Agile versterken elkaar als het gaat om de kwaliteit van de producten en diensten. Met agile en lean practices integreer je kwaliteit in de volledige productontwikkelingsketen.
In de workshop software kwaliteitsverbetering leer je hoe je goede producten en diensten kunt leveren. Kwaliteitsverbetering helpt organisaties om beter te voldoen aan de behoeften van de gebruikers en aan de eisen van de opdrachtgevers.
Mijn artikel Continue Verbetering met Agile is gepubliceerd in Bits&Chips nr 4. In dit artikel laat ik zien dat continue verbetering een integraal onderdeel is van de Agile-mindset en van de Agile-principes en -practices, en geef ik tips en advies voor verbeteren met agile:
Silver bullets bestaan niet in softwareontwikkeling. Effectieve softwareteams bepalen zelf hoe ze hun werk doen, passen zich continu aan en verbeteren zichzelf. Continue verbetering is ingebed in de Agile-mindset en -principes en helpt zo om de flexibiliteit in bedrijven te verhogen en meer waarde te leveren, betoogt Ben Linders.
Retrospectives Exercises Toolbox - Design your own valuable Retrospectives
Eerder dit jaar publiceerde Bits&Chips een Engelstalige editie, met daarin mijn artikel Delivering quality software with Agile.