This week we sponsored ProjectWorld in Toronto. Tons of people stopped by our booth and shared their experience with us.
As well as meeting many old friends and new potential clients/collaborators, Mishkin presented a symposium to dispel the myths of Agile work and Gerry, Travis, and I facilitated a workshop called “From Project to Product: Agile Delivery Models”.
Many people in our workshop asked that I share the slide deck so please download it here. Feel free to share with others!Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
Program Execution is one of the four core values of SAFe. Successful program execution is a result of a collaboration, including the key roles of the Product Owner, Release Train Engineer and Scrum Master. In a complex solution, multi-team environment, the role of the SAFe Scrum Master must be extended to include additional skills and practices beyond the traditional team-centric Scrum Master role.
To this end, Scaled Agile has just released the SAFe® Advanced Scrum Master course. As a next step in a Scrum Masters learning journey, this course will provide SAFe Scrum Masters with the necessary foundation to:
- Facilitate interactions with other Agile Teams, stakeholders, management and subject matter experts
- Support the adoption of scalable software, systems engineering and quality practices
- Apply Kanban to improve the flow of value
- Recognize and avoid Agile and Scrum anti-patterns
- Build high-performing Agile Teams
- Improve program performance with Inspect & Adapt
The SAFe Advanced Scrum Master course is built on the SAFe Lean-Agile principle of applying systems thinking in the context of the larger, system and enterprise. Agile Release Trains require capable Scrum Masters who help enhance the whole product solution, and systemically improve both team and program velocity by identifying and eliminating bottlenecks and impediments in the flow of value.
Attendees of the SAFe ASM course should meet the following prerequisites: Certified ScrumMaster® (CSM), or Professional Scrum Master (PSM), or equivalent experience. SAFe Practitioners (SPs) who have attended the SAFe Scrum Master Orientation may also attend.
Check out SAFe® ASM course calendar for a public class near you.
Be SAFe and help facilitate your enterprise’s better future!
SAFe Fellow, and SAFe® ASM course Product Owner
In a previous post, I defined Digital Transformation. But now it’s time to explain Digital Transformation, and make it real with examples.
Satya posted his mental model for Digital Transformation:
I like the simplicity.
What I like is there are four clear pillars or areas to look at for driving Digital Transformation:
What I also like is that this matches what I learned while driving Digital Business Transformation with our field with customers.Customer Experience Transformation
In terms of customers, you can engage with them in new ways. You can connect with your customers through apps that provide a mobile experience, so that your customers can interact with your organization, anywhere, anytime. You can listen to your customers through social listening and perform sentiment analysis. You can learn about your customer’s behaviors through telemetry insights that reveal what features your customers use and which ones they ignore. You can use data-driven insights to deliver personal experiences. With the insights you gain, you can segment your customers in more effective ways, and you can target new customer segments. You can use the Cloud to reach new customer segments around the world ,and you can test new experiences, and you can scale as needed. You can deliver a seamless and personal experience across all customer interactions, providing a true omni-channel experience.
You can push the envelope of customer interaction and drive deeper engagement with more immersive experiences.
By walking your customer journey, you can identify Digital Hot Spots—places where you can connect better, collaborate better, share information better, gain new insights, visualize better, or use infinite compute and infinite storage in new and exciting ways. And you can reveal new ways to create and capture value. This is innovating at the edge in action.
One example of customer experience transformation is the story of Real Madrid, the Spanish football club and the world’s #1 sports franchise. Previously, Real Madrid had just a one-way communication method for broadcasting information and news, to it’s 450 million fans, without the ability to get any feedback. Real Madrid wanted to know who their 450 million fans are, where they are, and what they want from them, so they could engage in more personal ways.
Fast forward to where are they now.
Real Madrid’s fan engagement platform captures and stores every interaction with a fan, including mobile check-ins at the club’s stadium, online fan profile updates, and online merchandise purchases. It also collects social media data from Twitter, Facebook, and other social media sites, for social segmentation of the individual fan, and analysis. Real Madrid’s extended video platform provides new and historical video content, including previous Real Madrid matches. Fans can filter searches to view specific games using criteria such as games where the club scored a certain number of goals.
Real Madrid’s consumer app lets fans virtually access the stadium before, during, or after each game, and they can search data on all the club’s players, past, and present, while exploring detail statistics from specific games. Real Madrid can now capture and discover personal preferences to provide more relevant content to their fan through the new mobile app, or when fans use the app to check in at the stadium, they an get a personal QR code for a loyalty in-stadium offer, or even a simple message that thanks the fan.Employee Experience Transformation
In terms of employees and workforce, you can change how people work together. Imagine if employees could bring their own devices and they can access the apps and information they need to do their job, anywhere, anytime to serve customers better. Imagine if employees can find the experts they need to collaborate with in real time. Imagine if they can discover the apps, the documents, the information, and the people they need to perform their work better, faster, and cheaper. Imagine if employees could connect with their peers, as well as with customers and partners to innovate on new ideas as well as solve problems better together.
Imagine if your workforce can “work out loud” in a more open way, leading to more connection and collaboration as employees learn to “work like a network.”
Imagine digital assistants that can help employees find the information they need, perform routine tasks, and guide them through new scenarios.
One example of employee experience transformation is the story of KUKA’s Intelligent Industrial Work Assistant. Employees are able to collaborate with robots to perform jobs better, easier, and faster than ever before. KUKA’s lightweight robot is able to sense its way around a complex task and perform precise automation movements safely and securely. This enables human-robot collaboration in new and exciting ways.
Another example is the story of the Edge. The Edge is a smart office space project that focuses on both a greener building and more productive occupants. The building connects and communicates with employees through the Edge smartphone app. The app helps employees find a parking spot at the building when they arrive. Then the app finds them a desk. Because at the Edge, employees don’t have one. No one does. Workspaces are based on their schedule: sitting desk, standing desk, work booth, meeting room, balcony seat, or “concentration room.” This helps
Wherever they go, the app knows their preferences for light and temperature, and it tweaks the environment accordingly. Side note – the Edge is the greenest building in the world. The British rating agency BREEAM, gave it the highest sustainability score ever awarded: 98.4 percent.Operations Transformation
In terms of operations transformation, you can improve process visibility end-to-end, increase decision making speed, and improve collaboration across silos. Another key to operations transformation is getting information to the people who need it most, when they need it most.
With machine learning, you can use predictive maintenance to replace parts before they break, provide just enough maintenance when you need it, and avoid expensive downtime. With predictive analytics, you can more intelligently optimize your schedule or logistics, or even figure out your next best offer to promote.
DevOps models and practices help drive continual delivery and IT service delivery agility. By promoting better communication, collaboration, and integration between software development and IT operations, DevOps helps produce software and IT services more frequently, with rapid iterations.
An example of operations transformation is the story of Fujitsu. Fujitsu enabled managers, engineers and scientists to simultaneously manage product quality, process efficiency, and equipment performance. As Fujitsu CEO Hiroyuki Sakai put it: “…we are able to deliver real-time visualization of the engineering process for big data analytics to improve the entire production process and inform decision-making.”
An example of operations transformation in healthcare is the story of Dartmouth-Hitchcock. Dartmouth-Hitchcock Health System is piloting a highly coordinated, intensely personalized solution to provide visualizations and deep insights that will transform business operations.
An example of operations transformation in logistics & transportation is the story of Scania. Scania is a global company that delivers trucks, buses, and engines, as well as services in more than 100 countries. Scania developed a system in the Cloud that measures the entire transport flow of a mine, with data sent wirelessly every second from the trucks in the production flow to Scania’s field workshop. This allows them to calculate uptime and down times and have useful data to make decisions that affect operational efficiency in real time in their customers’ mining operations.
An example of predictive maintenance is the story of ThyssenKrupp. Using the Cloud, can ThyssenKrupp can guarantee a higher uptime percentage on our elevators to gain a competitive advantage. Drawing on the potential of the Internet of Things (IoT) by connecting its elevators to the cloud, gathering data from its sensors and systems and transforming that data into business insights, ThyssenKrupp is vastly improving operations.Product Transformation
Wrapping engineering teams around your customers creates a new world of possibilities. By engaging with your customers more deeply, you gain new insights into their pains, needs, and desired outcomes that you can use to shape and create new products and offerings.
You can use your social insight and sentiment analysis to gain even deeper understanding of how to create and capture value for your customers.
Best of all, you can use telemetry to figure out what features your customers actually use and which features your customers ignore.
An example of product transformation in automotive is the story of Delphi Automotive. Delphi Automotive created Delphi Connect to give drivers many exciting ways to remotely monitor and control their cars. Delphi Connect can turn any car into a connected car with affordable, cloud-based telematics.
Another example of product transformation in automotive is the story of Qoros. Qoros engaged Microsoft Services to design and build the Qoros telematics system, which it calls the QorosQloud. QorosQloud provides more than 30 services, which can be also accessed from the driver’s smartphone, tablet, or PC, delivering functionality that goes beyond driving and the car. Vendors can provide data to QorosQloud—traffic data, points of interest, restaurant reviews, parking data and so forth. Qoros owners tell their car which points of interest they want to see on their in-car monitor. QorosQloud connects to the Qoros dealer management system, customer relationship management, company websites, mobile apps, and other business systems that run both in the Cloud and on-premises in a small Qoros datacenter.Business Model Innovation
Collectively, these four Digital Transformation pillars (customers, employees, operations, and products) set the stage for transforming your business model. According to The Business Model Navigator, you can think of your business model in terms of four components:
- Customer – Who are your target customers? (This is the heart of your business model, and it’s where your customer segments come into play.)
- Value Proposition – What do you offer to your customers? (This is where your products and services come into play.)
- Value Chain – How do you produce your offerings? (This is where supply chain optimization can have profound impact.)
- Profit Mechanism – Why does it generate a profit? (This is where reducing cost structures and adding profit generating mechanisms come into play.)
Business model innovation is a significant change in two or more part of your business model.
When you think through your business model, imagine if you could use the Cloud to reach new customer segments in emerging markets. Or, imagine if you could completely change your supply chain. Imagine if you can take an idea that’s working in another industry and bring it into your industry.
Another way to think about business model innovation in a mobile-first, cloud-first world is to think about new digital products you can create as you shift your mix from physical things to digital things for the digital economy.
Here are a few examples of business model innovation that you are likely familiar with:
- AirBnB is a large hospitality provider, but it doesn’t own any real estate.
- Netflix is a large movie rental service, but it doesn’t provide any physical retail stores.
- Uber is a large taxi service, but does not own any cars.
In the TED Talk: The Currency of the New Economy is Trust, Rachel Botsman provides a good overview of how service networking, the collaborative consumption, and the sharing economy are changing business models.Putting it All Together
When it comes to Digital Transformation it helps to have an all up mental model to work from. The more you can model and map out your Digital Transformation, the more effective you will be.
In the article, Microsoft IT cloud computing strategies continue to evolve, you can see how Microsoft’s IT department is going through it’s multi-year Digital Transformation journey.
In the article The systems approach on how to transform your digital healthcare organization, you can see some healthcare examples of the Digital Transformation pillars in action, such as customer experience transformation and operations transformation.
In the article Welcome to the Digital Revolution, you can get a really good overview of the big picture of Digital Transformation that is happening all around us.
Now that you know what kinds of Digital Transformation are taking place, along with concrete examples of Digital Transformation in the real world, hopefully that inspires you to re-imagine what you can do in a mobile-first, cloud-first world.You Might Also Like
“Resources” are fully allocated to capacity, “Features” are being developed, Stakeholders are happy – what could be better?
Scratch the surface however, and this thin veneer of accomplishment begins to show the truth that lies right beneath.
It doesn’t happen overnight, and it is almost always with the best intentions, but before you know it a functioning organization becomes a dysfunctioning one – how do we let this happen? Why does it happen again and again? Why don’t we recognize the difference?
Let’s explore some patterns and solutions that can help us get out of the rut.
Dysfunction 1: Output vs. Outcome
Being busy at work is a good thing – it should mean that you have enough to do at your job that you have a day filled with meaningful activities. Not just any activities, but ones that add value to the product or project – that if you think about them, actually add measurable change to your team. This kind of day requires that there is a well managed stream of work, people who have the skills we need to perform the work, and managers that are interested in growing the skills and abilities of their team.
That is not what I usually see when I first begin working with a new organization – I see resources that are allocated to account for 40 hours a week of assignments. I see overworked and overwhelmed or underworked and underwhelming employees – I see lots of folks show up – make noise, cause distractions, crete drama and come back the next day to do it again. I see employees that find new jobs as soon as they can to get out of the dysfunction – I see others that keep the dysfunction alive to hide the fact that they produce and contribute nothing. What this usually means is that I have individuals that someone treats as place holders for space and time on a spreadsheet so that instead of having to manage outcomes they will manage outputs.
The first step we take is to treat our resources as people – when we remove the language that identifies people as things, we begin to think of people as assets. Assets are valuable and we tend to care for valuable things. The second step is to start considering what people are producing and not how many hours they are in the office. The truth is that no one is working non-stop for 8 hours a day. It is also vey unlikely that allocating people to 10 different projects at any given time will produce valuable results. What we need to do is understand that our capacity is more limited than we would like and that more work in progress is different than completing more work more quickly. Then we build teams – teams of people that can take accountability for how they do the work they do. The amount of effort that goes into managing times then applied to managing productive outcomes. It’s hard to manage time on a spreadsheet – it’s easier to manage teams of people dedicated to your goals.
Dysfunction 2: If we build it…..
Let’s just say that we have addressed Dysfunction 1. We now have a satisfied and motivated workforce – what should they be doing?
I hear this a lot when I inquire as to what and why organizations are building what they are building: If we build it, they will like it. Then I ask who is using the thing? – “No one”, who asked for the thing? – “Our VP of…”, who is talking to the customer? – “No one”.
If we build it, they will come is a great idea for a movie plot, but not so good for an organization that is spending large sums of money to build things. How did this become a common pattern? It’s not too hard to figure out why – the people we build things for didn’t like the fact that we build things without including them, so time after time of disappointment, we stop talking to each other. What does a product or technology organization do then? Now as you are reading this you say – “Well clearly that makes no sense”, but you would be surprised how often this happens. The first step here is to begin to build a partnership with our customers & stakeholders – we need to begin again from the perspective that we are all one organization with a common goal to be successful. Success can mean a lot of things, but usually it means that we are making money.
Now it’s not easy, and a bunch of people will have to check some ego at the door, but the only way to get it done is to start talking – what are our common goals?; what is our vision for our product or project?; how can we ensure that we are building something valuable and useful? In this case, let’s build backlogs. Backlogs tell us what we want to build, they give us definitive information to have conversations with our teams and stakeholders around, and they give us a view into what we are actually intending to produce.
Dysfunction 3: Truth or Consequences
The 3rd Dysfunction is the most difficult to identify and address – not that it isn’t obvious, it’s that it’s hard to see when you’re in it. The 3rd Dysfunction involves the ability to be introspective – is your company telling itself the truth or a lie? It is not unusual for someone to tell me, “we are more productive than we have ever been – our teams are cranking out software!”, digging a little deeper and I find teams building software no one will ever use, no one has asked for and no one can define the value for. Are people crazy? Are they in another world? No. They are fooling themselves that being busy is being productive – but maybe worse – they have institutionalized this way of thinking.
Dysfunction 3 is a tough one, but we can solve this one too. Let’s produce working tested software and put it into production. In other words, let’s build relationships and communication with our teams, customers & stakeholders with real feedback from real people. Let’s start listening and learning from our real interactions.
Is the journey to tackling the dysfunction easy? No. Can they be reduced overnight? No. But recognizing the patterns is the first step in addressing high functioning dysfunction.
Think Scrum’s days are numbered? Think again.
As excitement around lean software development and Kanban exploded around 2010, there was no shortage of people proclaiming that we had arrived in a post-Scrum world. Some even went so far as to predict that Scrum would soon go the way of the 8-track.
But as I look at VersionOne’s State of Agile reports over the past 10 years, it’s clear that there were a lot of false prophets. Since we published the first State of Agile report back in 2006 with 722 respondents, Scrum has remained on top of the heap as the most-used agile “methodology”.
In 2006 the numbers looked like this:
When you consider that the “Hybrid/Custom” approaches probably had a significant amount of Scrum baked into them, Scrum users made up somewhere around 50% of the survey respondents.
Fast forward to 2016, and this is what we see:
Scrum’s impact in the latest survey really shakes out like this:
- Scrum – 58%
- Scrum + Scrum/XP Hybrid – 68%
- Scrum + Scrum/XP Hybrid + Scrumban – 75%
Making some assumptions about the “Custom Hybrids”, Scrum probably comes in somewhere north of 80%.
Flipping ahead a few pages in the survey results, we see that the leading scaling approach is “Scrum/Scrum of Scrums”, with SAFe® coming in a distant second. One thing these approaches have in common is that Scrum is the team-level engine. (Yes, SAFe does include Kanban at the team level now, but it is couched within an iterative framework.)
So why is Scrum still so pervasive?
In my opinion, Scrum’s appeal has always been its simplicity: few roles, few rules, and a focus on getting to Done. That minimalism remains as refreshing two years into an agile transformation as it is on day one.
I believe that most people understand now that, even within a single organization, Scrum’s a better fit in some situations, Kanban is better in others, and some hybrid approach is better in others. There was never any basis for the methodology wars or the predictions of the ascent of one and the demise of others.
You’ll be hard-pressed to find a pure Scrum shop these days. By “pure” I mean where they’re working to the Scrum framework, while banning the use of any XP engineering practices and forbidding the use of things like WIP limits.
The State of Agile Report asks what methodology is followed “most closely”. I’d bet that if we took away the option to select Scrum by itself, the percentage of Scrum-infused methodologies would still total up to about the same as they do now.
As with everything else, the market will decide if there’s ever a clear methodology winner. One thing that’s certain, though, is that the reports of Scrum’s impending death have been greatly exaggerated.
Find out more by downloading the 10th annual State of Agile Report and reviewing archives of past reports.
State of Agile is a trademark of VersionOne Inc.
The post State of Agile: Still Scrumming After All These Years appeared first on The Agile Management Blog.
Being busy is either our procrastination strategy or else our inability to organize our lives well. Busy people are perceived as important. They even feel they’re important. But, being busy isn’t to be productive. A 100% workload leaves us with no time to take on new important tasks.
People who were asked to calculate their hourly wage before listening to a short piece of music, were more impatient while the music was playing. They wanted to do something more profitable. The widening gap nowadays between can-do and doing is also busyness driving.
Tim Ferriss wrote that the options are almost limitless for creating busyness. Why not commit yourself to produce quantities of documents? Or else you can make sure you have key roles in all ongoing projects. Above all, be a link in as many chain of commands as possible.
The busyness fills our calendar with meetings and other hardscapes. Thus, we can never deliver what we committed to at those meetings. It’ll overload our cognitive capacity. Fight-or-flight mode will crowd out our analytical proficiency. Priorities become inflexible.
Idleness is, paradoxically, necessary to getting any work done. You’ll see the wholeness and make unexpected connections. And replacing unpredictable deadlines with timeboxing makes you more adaptable to change. A good start is to never use the word busy as an answer.
 DeVoe S. E., House J. – Time, money, and happiness: How does putting a price on time affect our ability to smell the roses?, Journal of Experimental Social Psychology, Volume 48, Issue 2, March 2012.
 Ferriss T. – The 4-Hour Work Week: Escape the 9-5, Live Anywhere and Join the New Rich, Random House, 2007.
 Kreider T. – We Learn Nothing: Essays and Cartoons, Simon and Schuster, 2012.
A few years back, I went to visit a company that had managed to achieve a high level of agility without high levels of coaching or training, shipping several times a day. I was curious as to how they had done it. It turned out to be a product of a highly experimental culture, and we spent a whole day swapping my BDD knowledge for their stories of how they managed to reach the place they were in.
While I was there, I saw a very interesting graph that looked a bit like this:
“That’s interesting,” I said. “Is that your bug count over time? What happened?”
“Well,” one of them said, “we realised our bug count was growing, so we hired a new developer. We thought we’d rotate our existing team through a bug-fixing role, and we hypothesized that it would bring the bug count down. And it worked, for a while – that’s the first dip. It worked so well, we thought we’d hire another developer, so that we could rotate another team member, and we thought that would get rid of the bugs… but they started going up again.”
“Ah,” I said wisely. “The developer was no good?” (Human beings like to spot patterns and think they understand root causes – and I’m human too.)
“Nope.” They were all smiling, waiting for me to guess.
“Two new people was just too many? They got complacent because someone was fixing the bugs? The existing team was fed up of the bug-fixing role?” I ran through all the causes I could think of.
“All right. Who was writing the bugs?” I asked.
I was confused.
“The bugs were already there,” one of them explained. “The users had spotted that we were fixing them, and started reporting them. The bug count going up… that was a good thing.”
And I looked at the graph, and suddenly understood. I didn’t know Cynefin back then, and I didn’t understand complexity, but I did understand perverse incentives, and here was a positive version. In retrospect, the cause was obvious. It’s the same reason why crime goes up when policemen patrol the streets; because it’s easier to report it.
Conversely, a good way to have a low bug count is to make it hard to report. I spent a good few years working in Waterfall environments, and I can remember the arguments I had about whether something in my work was genuinely a bug or not… making it much harder for anyone testing my code, which meant I looked like a good developer (I really wasn’t).
Whenever we do anything in a complex system, we get unexpected side-effects. Another example of this is the Hawthorne effect, which goes something like this:
“Do you work better in this factory if we turn the lights up?”
“Do you work better if we turn the lights down?” (Just checking our null hypothesis…)
“What? Um, that’s confusing… do you work better with the lights up, or down?”
“We don’t care; just stop watching us.”
We’ve all come across examples of perverse incentives, which are another kind of unintended consequence. This is what happens when you turn measurements into targets.
When you’re creating a probe, it’s important to have a way of knowing it’s succeeding or failing, it’s true… but the signs of success or failure may only be clear in retrospect. A lot of people who create experiments to try get hung up on one hypothesis, and as a result they obsess over one perceived cause, or one measurement. In the process they might miss signs that the experiment is succeeding or failing, or even misinterpret one as the other.
Rather than having a hypothesis, in complexity, we want coherence – a realistic reason for thinking that the probe might have a good impact, with the understanding that we might not necessarily get the particular outcome we’re thinking of. This is why I get people creating probes to run through multiple scenarios of success or failure, so they think about what things they might want to be watching, or how they can put appropriate signals in place, to which they can apply some common sense in retrospect.
As we’ve seen, watching is itself an intervention… so you probably want to make sure it’s safe-to-fail.
We’ve always focused the bulk of our attention on making Tracker a straightforward—yet powerful—tool to help you deliver fine software.
It’s grown into quite the precocious 10-year-old as a result though, and we felt it was about time to tackle Tracker’s 180 FAQ collection. We’ve revamped all of our help material and put it into one glorious, easily searchable spot. Here it is—the new Tracker Help Center.
Click Help at the top right of Tracker, or in the footer, to get to the above landing page. Clicking on Search results or a button takes you to all the content you need.
Once there, along with a big Search box, you’ll find a navigation sidebar to take you from the introductory steps all the way to wringing every last drop of project delivery goodness from Tracker. You’ll find a Quick Start section, which provides a few steps and short videos to get you using Tracker within minutes. The practical Getting Started material includes Tracker Terminology so that we can speak the same language. That’s followed by Getting More, with in-depth info and good practice guides. There are plenty of handy tips and notes throughout that should help even the most seasoned Tracker user enhance their experience.
Last but not least, there’s information on how to send your feature requests and feedback, check on system status, find troubleshooting tips, and just get in touch for any answers you can’t find.
Please tell us what you think, and what else you need from our Help Center. We’ll update it as Tracker continues to improve, but you also can shape its content with your requests. So please do! As always, we’d love to hear from you and are flattered if you follow us for updates on Twitter.
I recently had a conversation in the WatchMeCode slack where someone was asking about the order in which various parts of Express middleware would fire.
After some initial thoughts on the question, I found myself not 100% certain of the order between calls to “.use”, vs get/post/etc. So I whipped up a quick demo app to see what would happen when I put things in different places.The Sample Code
The code I came up with is fairly straightforward, with a call to “.get” and “.param”, and 2 calls to “.use” at various times:
This provides a good cross-section of the major parts of an express route handler setup.
On running this code, however, I found it didn’t quite work as I expected.The Output
When making a request to “/foo” on my localhost, I knew “.param” call would fire before the route handler. I use param all the time, so this was expected.
My initial expectation of the “.use” calls, however, was not quite right.
I expected them both to fire before the “.get” call. What I got for the output, instead, was this:
Note that the “second use” console log message never shows up!
It turns out the order in which you add the middleware is important. And since the 2nd “use” method is added after the “get” handler, it is never called.
The “get” handler short-circuits the middleware when it renders the page, preventing any further middleware from being processed.Middleware Ordering
What I learned from this quick experiment, is that almost all Express middleware is treated equally when it comes to the order in which it executes.
With the exception of “.param” always happening just before any route handler that matches the parameter, the order in which your route handlers and other middleware functions are declared is the order which they will be executed.
This is true for all levels of your routing and middleware configuration. Whether you are dealing with a router instances, adding sub-routers or working with the top level Express application instance, calling .use, .get/post/etc, or any other middleware method will result in the code executing in that order.
The next time you’re wondering when your middleware will execute, then, just look at the order in which it was declared. You’ll know, with certainty, when the code will be called.
This “Highlights” series captures the SAFe news and activities that haven’t been covered in other posts, but would still provide real value to the community. Here’s the latest roundup—a mix of SAFe events, new perspectives, understanding, and practical steps for successful implementation of the Framework.
2016 Scaled Agile Summit – Save the Date October 25–28
The SAFe event of the year is in the works, and the full registration site is coming soon. Join the Summit mailing list and be the first to get the latest updates on registration, earlybird discounts, speaker announcements and more.
New SAFe Advanced Scrum Master (ASM) Course
The much awaited SAFe® 4.0 Advanced Scrum Master course has been added to Scaled Agile’s role-based curriculum offering. Click here to learn more about the course. Public classes are available in multiple cities, including Boulder, Philiadelphia, Santa Clara, Washington, DC, and Atlanta.
SAFe LinkedIn Group Reaches 10K Milestone
If you haven’t yet joined this group, you’re missing out on the single, most active community of practice dedicated to SAFe. It’s a hotbed of questions, answers, advice, fast feedback, and debate. Click here to join the group!
SAFe 4.0 in plain English
From the Portfolio Kanban and Metrics to the Value Stream and Solution Intent feature, this TechBeacon article uses plain english to explain some of the key new features in SAFe 4.0.
Agile Software Inside a Waterfall
This news blog for the medical device industry drives the idea that the highly regulated medical device industry is now actively using SAFe (and other Agile methods) as part of a greater movement toward acceptance of Agile methods by the FDA and the Association for the Advancement of Medical Instrumentation.
The Lean-Agile Enterprise Awakens: Scalable and Modular is the Future!
In this Agile India Keynote presentation, SAFe Fellow Richard Knaster discusses a more scalable and modular lean-agile approach that enables even the largest enterprises to compete with smaller and nimbler competitors that are disrupting companies in all industries.
Ovum calls out SAFe as factor in citing IBM as market leader in App Dev for Hybrid Cloud
Scaled Agile Partner, IBM, was called out as a market leader in three areas that are key to creating hybrid cloud environments: DevOps release management, application lifecycle management (ALM), and Agile project management. Regarding ALM, the research firm praised IBM for its support of the Scaled Agile Framework for enterprise agile development at large scale.
SAFe jumps to #2 position in 10th Annual State of Agile Survey
Based on over 3,800 responses, VersionOne’s 10th Annual State of Agile Survey confirms that Agile methods deliver tangible benefits and are steadily becoming the default approach to software development, as well as areas outside software. SAFe saw the largest increase in adoption rates—from 19% to 27%—in Scaling Methods and Approaches, making it the second most prevalent scaling method cited by respondents after Scrum of Scrums.
We’ll keep rounding up these great resources for the community, so stay tuned to the blog.
In the meantime, stay SAFe!
spike: evaluate TinyMCE / other options for editing text in forumWe got to the end of the evaluation, and as PO, I had more questions at the end of this evaluation than at the beginning! Why?
I think the answer can be found in the title of the spike. What's wrong with this title? First, it starts with an verb in the imperative. "Team, do this" It is not an invitation to think. Second how do we know if the we have satisfied the objective? It doesn't really say. It just says 'evaluate.'
Here's an improvement:
spike: can we eliminate our copy/paste problems by using TinyMCE?By formulating the spike as a question, it becomes clearer what is the objective of the spike. This in turn makes it easier to tell whether the spike is done.
Of course, this still doesn't answer the question of whether it is a good thing to deploy it in our context. It's a closed question and assumes part of the answer, i.e. that TinyMCE is the best solution. How about:
Which forum editor best satisfies the needs of our users?Of course, that might be a bigger spike, but the goal is clearest and most focussed on the people who really matter!
In my Certified Scrum classes, I demonstrate using Scrum in the class by organizing the class with Scrum. The course topics are the product backlog. I used to define the product backlog as user stories, but I now express them as questions. My students ask questions; learning is the result of asking questions; and formulating the product backlog as a series of questions seems like a natural approach. I wonder questions as backlog items could be used for other kinds of story as well?
Does it make a difference when it comes to the application performance vs the readability and expressed intent of the code?
In this episode of ThoughtsOnCode, Derick answers these questions from a viewer, diving into the idea of performance optimization and measurement.Further Reading
The above video takes a very intuitive approach to the subject of performance, advocating measurement over generalized “best practices” for performance.
If you’d like to get more detail on why I believe this, and look at some actual numbers, though, check out this blog post from Kyle Simpson:
In this post, Kyle walks through the most common object creation patterns and puts actual numbers on screen, comparing real scenarios in application development.
The result of Kyle’s research is very much in agreement with my statements above.
As you guys probably know, the Agile2016 conference is in Atlanta this year. What you might not know, LeadingAgile is in Atlanta as well. Given that the conference is in our home town, we’ve decided to throw a big, big party and all you guys are invited.
with special guests Kick the Robot
July 27, 2016
The Tablernacle, Atlanta, Ga
Doors open 7:00 PM
We’ve rented out the iconic Tabernacle, within walking distance of the conference, and have enlisted my favorite band in the whole world… Collective Soul… and one of my new favorite bands… Kick the Robot… to come entertain us.
And here is the cool thing… the bands are from Atlanta too!
The concert is free, but you have to register and let us know you want to attend. If you’re in town for the conference, or just simply in town, go to collectivesoul.leadingagile.com and enter the code BLOG to unlock the registration process.
You can register for as many tickets as you want until we are sold out. All I ask is if you take a ticket, please do your best to make it. We really want to pack the house and make this the most fun agile event ever.
If in the unlikely event you aren’t familiar with Collective Soul, you are totally missing out. You can find out more about the band on the registration site, or hit their website directly at www.collectivesoul.com.
I wouldn’t be surprised if you haven’t heard of Kick the Robot, they are new, but totally awesome. They are a throwback to T-Rex, the Beatles, and David Bowie, mixed with a healthy dose of Cheap Trick and the Kinks. You can check them out at www.kicktherobot.com.
As an extra special treat… Collective Soul said I could get up and play a song with them. So… you just might see me on stage with a guitar if you hang around for the encore ;-)
Really hope you can make it. See you there!
Many people have commented on the statement that Kent Beck made in Snowbird around his purpose for the meeting. I wasn’t there of course, so I am most likely paraphrasing, but the generally accepted representation was that he wanted to “heal the rift between development and the business”. As I was attending the first of the conference season
events, Mile High Agile, I started to wonder how well that has worked. I’m not thrilled with what my conclusions currently are. I’m hoping someone can show me where I’m wrong.
First, some history. This might seem a little self-indulgent, but I promise that I do have a point, if only to set some context. I discovered eXtreme Programming back around 1999. I read the book and rejected it, until I met people who were doing it. It was truly revelatory. People were happy. The business oriented folks were working together collaboratively with the rest of the team. Not at a daily meeting, but throughout the day. I started digging deeper and realized that someone had finally found a way to make software that managed the balancing act between good engineering and good project management. With that in mind, I went to the first XP Universe. I left even more energized and ready to take on the world.
The next few years were fun and challenging. Most of my time was spent practicing and evangelizing XP, and then agile came along. I continued to be part of development, and attended many, many conferences and discussion groups. And that is where it gets weird. At the early conferences, the mix between developer and manager/project manager was a little lopsided toward the programmers.
Then there was a shift and all of a sudden it was hard to find someone at the conference who wasn’t a Scrum Master, the head of a PMO, a senior portfolio project manager, CSM, CSPO, SA, or EIEIO. Several keynote speakers who I really admire started asking, “where are the programmers?” This has led me to wonder, what now? The rift was starting to heal, but it seems to be growing wider again. Far too much attention is being spent on “what processes and tools do we need” and not enough on “how can we deliver working software?” What can we do to reverse this trend?
So, now that I’ve indulged in reminiscences, it’s time to do something about it. I’m not a big fan of just sitting around arguing over a course of action without actually doing something about it. So let’s get the software development back into agile software development.
We can begin by refusing to accept a separation of “management practices” and “technical practices”. There are just agile practices. The next time we’re going to spend training money on agile stuff, let’s skip the story writing and framework training, and let’s spend it on test driven development (TDD) or refactoring. Better yet, let’s spend that time and energy on DevOps. And don’t just send “Dev” to these classes. Wouldn’t it be cool if the technical folks had the same understanding of what agile means? And the next time you’re inclined to ask for or write another report about “progress”, ask yourself “can I express this in terms of working software?”
So this is my call to action: The time for the healing to start again is now. What will you do to make it happen?