There are a lot of great aspects of software development, including writing code, solving problems, and generally working with cool technology and toys.
But of all the things that I do as a developer, there is 1 thing in particular that I absolutely love doing. And that one thing? It’s not solving problems, surprisingly (though this is probably a close 2nd).Tweet
One of the easy mistakes in building a REST API is trying to take your rows out of the database and expose them directly as JSON. Such technology exists, where you can directly expose stored procedures as SOAP web services, or protocols like OData. You can also just expose your entities directly as JSON through a web service, but you’re missing out on some big distinctions of resources and representations.
So first, what is a resource? That’s actually quite easy – a resource is anything with a URL. The converse is not true, a URL is not a resource, mainly because the URL is the Uniform Resource Locator. If you can locate a resource, then it exists. And Fielding was pleased.
The representation is a bit different – it describes the current state of the resource (when requested).
So what does this have to do with entities? Well, nothing. There is no relationship between entities and resources. And that’s a good thing, it’s exactly how the web works.
When you navigate to a web page, an online retailer, and look at a list of products, what is the resource? From the client’s perspective, we don’t know. We have no idea of the implementation details of the resource, other than a way to locate it and request a representation. Again, Fielding was pleased, as this decoupled us from the implementation details of the resource.
So where does this leave us when building APIs?A decoupled API
In APIs that serve the client according to their needs, the resource often includes details from many different data sources, combined together to build a representation to the end user. A REST API builds all this together:
In hypermedia APIs I build, the resource state combines multiple entities together from one or more data sources into the state of the resource. This plus links, forms a queries makes a “resource”, though it’s still a bit more abstract than that. Finally I build out the representation, perhaps JSON API, HAL, Siren etc.
If I made my entities equivalent to resources, I’m likely forcing clients to make many round trips to all the entities they need, but even more, I’m directly exposing the implementation details of my service to the world. Perhaps I’m removing some fields here and there, but in reality this is only one step above handing clients a connection string to my database. Sure, it’s easy and convenient to expose entities directly as resources and representations, but there’s some serious coupling that comes with that choice that you must accept.
In my experience, if I approach the API design strictly from the client perspective, on what they’re trying to achieve and why, it’s actually quite rare that I arrive at an API design that is simply database CRUD exposed as HTTP. And Fielding was pleased, as this design most closely matches the everyday use of the web. Makes sense. That’s what REST is about – a set of architectural constraints describing basically, the web.
Post Footer automatically generated by Add Post Footer Plugin for wordpress.
Effective and continuous delivery of value through execution of Program Increments (PIs) is a hallmark of successful SAFe programs. Product Managers and Product Owners help drive that value by defining and sequencing the team and program backlogs. To succeed, they must have the knowledge and training needed to perform effectively in a SAFe environment.
To this end, we are happy to announce the release of a new SAFe 4.0 PM/PO course with certification. This course will enable the PM/PO team to effectively navigate their role in a SAFe Enterprise, and provide the tools needed to support product development flow and continuous value delivery.
The course is based on the lessons we’ve learned from years of working with PMs and POs as they launch, maintain, learn and adapt through Agile Release Train (ART) execution. After attending this course, PMs and POs will be able to:
- Connect the core Lean-Agile principles and values to their individual contributions
- Take an economic view when prioritizing their backlogs and executing PI
- Identify PM/PO responsibilities within a SAFe implementation
- Contribute to portfolio content
- Integrate Solution delivery in complex environments
- Drive customer value as a Product Manager
- Increase value delivery at the Team level as a Product Owner
- Engage with stakeholders
- Build and grow Communities of Practice to further their knowledge of their own disciplines
- Take the exam to achieve SAFe PMPO Certification
Individuals that would benefit from this course include: Product Managers, Product Line Managers, Product Owners, Business Owners, and Business Analysts. Others include Solution Managers, Portfolio Managers, Program Managers, Architects, PMO personnel, and Process Leads.
Attendees of the SAFe 4.0 PM/PO course should meet the following prerequisites: Leading SAFe, SAFe Live Lessons, or equivalent SAFe implementation experience.
Visit the SAFe 4.0 PM/PO course calendar for a public class near you.
We look forward to seeing you in class.
SAFe Fellow, and Product Owner: SAFe 4.0 PM/PO course
Oh, and I was so curious about how many female/male managers there were, we had to ask that question. Yes, I said to Marcus, “We have to ask!” He laughed and added that question.
It should take you less than 10 minutes to fill out the survey. We will leave the survey open for no more than a couple of weeks. We’ll send the results to people who asked for it, along with publishing the results in the article we are writing.
We will not add your name to any email lists. It’s safe for your mailbox to take the survey. The link is Software leadership 2016 survey.
Recently, I was engaged in a lively conversation about enterprise agile transformations and the topic turned to Project Management Offices (PMOs) and, specifically, Project Managers (PMs). The gentleman I was speaking with said that in ideal agile, there is “no need for Project Managers”. His argument was that they are replaced by Product Owners, Delivery Teams, ScrumMasters, and/or Functional Managers.
At first glance, there may appear to be merit to his statements. Let’s look at some of the evidence:
- In most agile methodologies and frameworks, there is no Project Manager role. In fact, there might not be projects at all.
- No need to build teams around a project – teams are stable and work is brought to the team.
- No need to manage scope and build detailed GANTT charts – that is done by Product Owners through a well-defined, prioritized backlog.
- No need to gather individual estimates – that is done by the teams progressively.
- No need to gather individual progress status – that is done through working, tested software and burning down work.
So was the gentleman correct? I contend that he was not, especially as you start to scale agile in larger organizations. In fact, in my experience, buy-in and alignment of the PMO and Project Managers could make or break your transformation.
I will not deny that the traditional role and responsibilities of a Project Manager changes and may be distributed in agile, however, the skills and experience PMs bring to the table are extremely valuable.
Effective Project Managers have good organization and communication skills. They are well versed in risk and dependency management. They understand ways to manage time, cost, and scope. They know the organization and how to remove impediments.
So what becomes of Project management in an enterprise agile world? There are many roles a traditional Project Manager can play. One such role is as a Portfolio Manager on a Portfolio Team.
The Portfolio Team is responsible for setting the vision and strategy, deciding on initiatives in which to invest, and ensuring value is aligned with business strategies. The Portfolio Manager helps make sure that the team has everything it needs to function effectively. This goes beyond just scheduling recurring meetings. The Portfolio Manager can act as a servant leader, removing impediments, measuring progress, and enabling the team to make decisions on the portfolio.
The Portfolio Manager is the facilitator for the team. They help keep the team accountable to adhering to processes and working agreements, as well as ensuring the team operates efficiently.
Another role could be that of a Program Manager on a Product Owner team. As an organization scales, it becomes difficult to manage dependencies and risks. It becomes overwhelming for a Product Owner to provide clarity of the backlog to their delivery teams.
By forming a team around a Product Owner, many individuals can lend support and capacity to the Product Owner, providing delivery teams that backlog clarity. A vital part of that team is the Program Manager. They help to clear impediments, manage dependencies and risks, hold the team accountable to providing all the things necessary to ensure the delivery teams are never starved of requirements. They can also serve as an escalation point for blocks and issues that cannot be resolved within the delivery teams.
Other areas and roles a traditional Project Manager could serve or grow into include Release Manager, ScrumMaster, Community or Practice Lead, Product Owner, or Internal Coach. I tell Project Managers to really think about their long term career goals and be proactive in pursuing those areas of interest.
The biggest lesson I try to impart is how to be a servant leader. Changing your mindset from directing to serving can be difficult. But, in an Agile world, servant leadership is what is needed to be truly successful. Enabling others to be successful, will make the organization and the individual successful. When the teams win, everyone wins.
I encourage Project Managers to seek opportunities where they can help the organization and the transformation. With a Project Management background and a servant leader mindset, PMs can grow into incredibly effective agents of change.
- Sponsored: 64% off Code Black Drone with HD Camera
Our #1 Best-Selling Drone--Meet the Dark Night of the Sky!
Recently, I’ve been doing a lot of reflecting on how to increase personal agility. No, I’m not talking about doing somersaults or some crazy yoga poses. I’m speaking of the ability to focus on the delivery of value and be adaptable in what I do every day. When the Manifesto was written back in 2001, there were representatives from Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others present. They focused on values and principles that would improve how we do software development. But, can we apply the same practices to our personal lives? I’ve been looking to answer that question since 2010, when I started to write about Personal Kanban. For me, Kanban doesn’t get the love it deserves, as a tool to help manage personal activities and outcomes. When people talk about agility, they usually think Scrum. I realized Scrum is being leveraged outside of software development. I was even approached recently to comment on “Agile” Marketing by using Scrum. It got me thinking… Why do people think Scrum will solve all problems? When it comes to organizational agility and specifically personal agility, I don’t think it does.Scrum for One?
For the sake of this post, I want to keep focus on people and not big organizations. Having been an Agile coach and consultant, I have learned a lot of strategies that have helped me manage customers and accounts. While working with large complex organizations, I have seen productivity improvements on organizational levels by leveraging Lean and Kanban and on a team level by leveraging Scrum and Kanban. But what about all of the individuals who work for those organizations or on those Scrum teams? What about people who have no idea what Scrum is and don’t care? How can they better their productivity outside the software world?
In the Lifehack article “Scrum for One,” Dustin Wax described how many of the elements of Scrum could be adapted for individual productivity. When reading the article, I wasn’t sold on the idea. Scrum is an awesome framework for teams but I see it like jamming a round peg in square hole, if you want to use Scrum for your day-to-day productivity.
In Scrum, you demonstrate value to your customer or customer representative every 2-4 weeks, as part of a sprint (timebox). Does that make sense for managing your personal work on a continuous basis? No.
In Scrum, you have a 3 roles: ScrumMaster, Product Owner, and Team. Unless you have a split personality, it’s just you!
If the metaphor doesn’t align with reality, find a new metaphor versus trying to bend reality to reflect it.
Most of the things I think about when getting things done include: Aligning activities to outcomes, breaking work into managing chunks, iterating on what I’m doing or creating so it can be delivered or improved over time… With that, these are not elements exclusive to Scrum. So, why limit yourself to Scrum?Personal Agility Manifesto
I believe personal productivity (or agility) could to be rethought. Is personal productivity about being really busy or is it about getting things done? To be productive, it means you must produce. If not, you are just active. There is a difference! To help shape my thoughts, I wrote my own principles of a personal agility manifesto. It’s a lot like the Agile Manifesto.Principles of Personal Agility
I follow these principles:
My highest priority is to satisfy myself and then others
through early and continuous delivery of valuable outcomes.
Welcome requests, even late in the day.
Agility harnesses change for my competitive advantage.
Deliver outcomes frequently, from a couple of hours to a couple of days, with a preference to the shorter timescale.
Work together with others daily.
Outcomes are completed by me being motivated.
Get the environment and support I need, and get the job done.
The most efficient and effective method of conveying information
to and from others is face-to-face conversation.
Outcomes are the primary measure of progress.
Agile processes promote sustainable outcomes.
I need to maintain a constant pace indefinitely.
Continuous attention to technical excellence and craftsmanship enhances my agility.
Simplicity–the art of maximizing the amount of outcomes–is essential.
The best outcomes emerge from me being a self-organized individual.
At regular intervals, reflect on how I can become more effective,
then tune and adjust my behavior accordingly
First, (any) outcomes are the primary measure of progress. This isn’t all about software development.
Second, I’m focused on minutes, hours, and days to get things done. Teams will continue to focus on days, weeks, and months to get work done and shipped.Conclusion
I’m looking to dig into something anyone, within or without an Agile team, can use to improve personal productivity. When you hear “Agile” it’s actually a pretty niche group. But, when you talk personal productivity, the audience size explodes. Like with agile, I don’t think there is a single right way. So, I’m looking to experiment and continue to try and get better. So, if you are an individual, you can be agile for one. If you have any tips or tricks on how you get things done, I would love to hear them.
Agile teams gebruiken retrospectives om continu te verbeteren. Verbeteracties richten zich vaak op de manier waarop het team samenwerkt om de productiviteit te verbeteren. Uit een retrospective kunnen ook acties komen om de kwaliteit van het product te verbeteren. Bijvoorbeeld door verbetering van de manier waarop er getest wordt.
Tijdens een agile retrospective die ik faciliteerde kwam naar voren dat er veel software fouten gevonden waren in de systeemtest. Deze testen werden niet door het ontwikkelteam gedaan, maar door een apart testteam.
Zoek de oorzaak
Mbv een 5 keer waarom retrospective oefening werden de fouten geanalyseerd. Daaruit bleek dat het om functionele fouten ging, die door het ontwikkelteam tijdens de iteratie gevonden konden worden.
Een van de grondoorzaken was dat de test strategie die aan het begin van het project was opgesteld niet voldeed Er ontbraken regelmatig test cases in de funtionele test, waardoor er fouten doorheen slipten
Besloten werd om een verbeteractie te doen: voor iedere user story zou voortaan een acceptance test geschreven worden, die zou bestaan uit een lijst met functionele testcases die het team uitvoert. In de definition of done werd toegevoegd dat alle testen de status passed moeten hebben voordat de user story af is.
Door dit consequent te doen ging het aantal functionele fouten wat in de systeemtest gevonden werd aanzienlijk omlaag. Deze fouten werden al eerder gevonden of niet meer gemaakt door de verbeterde testanalyse die gedaan werd voordat de ontwikkelaar de software schreef.
Met de 5 keer waarom oefening in de retrospective leerde het team van hun fouten en definieerde ze acties om in de toekomst soortgelijke problemen te voorkomen.
Het uiteindelijke doel van retrospectives is om continu beter te worden. Wat beter precies is, dat weet het team het beste. Immers de teamleden weten hoe ze hun werk doen. Met de retrospective krijgen ze inzicht wat er goed gaat en wat beter kan.
Waardevolle Agile Retrospectives
Wil je meer weten over retrospectives? Luis Gonçalves en ik hebben het boek Getting Value out of Agile Retrospectives geschreven. Dit boek is vertaald door een team van vrijwilligers naar het Nederlands: Waardevolle Agile Retrospectives. Het boek helpt je om voordelen te halen uit het doen van retrospectives.
Retrospectives Exercises Toolbox - Design your own valuable Retrospectives
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.
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.
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.Tweet
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.Tweet