By LibertyGroup25 (Own work)
Henry Ford pioneered many of the ideas that are now commonplace in business, including ideas used in Design Thinking. He has been quoted as saying "If you ask people what they want, it would be a faster horse." This hits on the design thinking principle of divergence. You need to understand what problem you are solving before coming up with a solution. Henry Ford wasn't solving a problem around horses, he was solving a transportation problem.
I was in a design thinking workshop and we did an exercise where first we were asked to draw a door bell. Then we were given a problem in a different framing, we were asked to draw a way to know if someone was at the door. The second set of drawings were much different. A doorbell would have worked, but by reframing the question, many other solutions came out.
Another Henry Ford quote is "you can have any color, as long as it's black." On the surface, this might not sound very customer friendly, However, this response was due to the solution to another problem. When he was developing the production line for the Model T, he was challenged in the painting step. He found all paint colors took to long to dry, except black. By only offering black, he was actually fixing a bottle knock in his process...applying the theory of constraints as it were.
Next time you're working on a solution to a problem, spend a few minutes and think about the framing of the question. Can you change the question in order to expand you possible solutions?
Some recent discussion in the WatchMeCode slack spawned a bit of research into creating custom errors through factory methods, while keeping the stack trace for those errors clean, in Node.js
After a bit of digging, I found a good solution using Node’s Error.captureStackTrace method, and recorded a quick screencast to highlight it’s use.The Screencast The Sample Code
If you’d like to run the sample code that I showed in this screencast, you can grab it from this gist.Additional Resources
And if you would like to read up on errors further, check out these additional resources:
Op 21 juni geef ik de workshop Valuable Agile Retrospectives in Utrecht. In deze succesvolle workshop leer je de waarom, wat en hoe van retrospectives en oefen je in teams met diverse manieren om retrospectives uit te voeren. Continue reading →
- Organizational Design Without Empathy Won’t Work (Sam Spurlin)
- 0 Bugs Policy (Gal Zellermayer)
- How a Worker-Owned Tech Startup Found Investors—and Kept Its Values (Nathan Schneider)
- Embracing Agile (Harvard Business Review)
- Continuous Deployment at Instagram (Michael Gorven)
- Where the hell are all the great senior software developers and hands-on engineering directors? (Obie)
- The Ratio of Women Speakers in Tech (Phil Sturgeon)
- Giving better code reviews (Joel Kemp)
Image attribution: Freepik
- Sponsored: 64% off Code Black Drone with HD Camera
Our #1 Best-Selling Drone--Meet the Dark Night of the Sky!
I believe there are the two primary success factors in creating a thriving business: a culture where customers matter and employees matter. I’m not talking about the lip service that is prevalent today. In some cases, we see quite the opposite, where employees are disenfranchised and customers are rarely engaged. Instead, the goal is to have a culture and practices in place that truly gain the benefits of engaging with customers and employees. Through the customer and employee, a company draws their power within an agile culture and, I contend, within any thriving company. When you have a riveting focus on the customer and you believe that an engaged customer matters, then you have the basis for a relationship where you can truly understand what the customer wants. When you have a sharp focus on employees and provide them the space to make decisions and own their work, then you will begin to understand the value an engaged employee base can provide.
If the values are sincerely translated to organizational objectives and agile approaches are applied, then it can act as a differentiator between the success of your organization compared to the success of other organizations. Of course, every company likes to say that employees and customers matter, but are their objectives and actions really aligned with these values? Upon closer inspection, the values should translate into objectives focusing on customer engagement and employee engagement.
- Customer engagement focuses on establishing meaningful and honest customer relationships with the goal of initiating continuous customer feedback to truly identify what is valuable to the customer. This includes establishing all of the activities involved in a Customer Feedback Vision.
- Employee engagement focuses on empowering employees so they can self-organize into teams and can own and be a part of the decision-making process at their own level. When employees have ownership, they have more passion in their work. When they have more passion, they give 110%.
Then we add the “secret ingredient” of applying a continuous and adaptive approach (a.k.a. agile culture, processes, methods, practices, and techniques). If done properly with the ability to adapt, this can lead to an increase in customer sales and an increase in team productivity. This finally leads to your incentive, which is an increase in company profits.
Now is time to take a moment. Are employees disenfranchised or fully engaged? Are customers rarely engaged or is their feedback continuously engaged? Is Agile just a trend that others should do or are you serious about Agile and the culture shift it requires? Keep in mind, the combination of customer and employee engagement within an Agile context isn’t just a good idea, it is great for business.
PS - to read more about the importance of customers and employees, consider reading Chapter 3 of the book entitled Being Agile.
I first heard of SATURN via social media through Michael Keeling, an IBM employee who spoke at XP2009 many years ago. Sam Newman spoke last year about Microservices. Although the conference has a Call For Papers (CFP) each year, they also had a small number of invited speakers and Michael organised for me to go along to talk about Evolutionary Architecture.
SATURN is a conference organised by the SEI (Software Engineering Institute). SEI are probably most well known for CMM, although there is now another institute responsible for it. The conference has been running since 2005 and has a long history of focusing on architectural concerns.Architecting the Unknown keynote by Grady Booch (@Grady_Booch) What I really liked about the conference
I believe that one of SATURN’s greatest strengths is a focus on architectural thinking, through the application of the latest tools. Unlike some other conferences, I felt like the programme tried to assemble a good collection of experience reports and presentations that emphasised the architectural principles, rather than focusing on the current tools.
Although this may be less popular for people wanting to learn how to use a specific tool, I feel this emphasis is much more valuable and the lessons longer lasting.
What I also really enjoyed about the conference was the relatively small size which was just over 200 participants from various parts of the world. Having a good location, and small size allowed for some better quality conversations both with other speakers and attendees. One good example of the conference facilitating this, was an office hours session for attendees to easily ask questions of speakers. I shared by office hours with Eoin Woods (author of Software Systems Architecture) and Grady Booch (IBM Fellow, One of the Three Amigos who were best known for developing the Unified Modeling Language).Conference dinner at a baseball game for SATURN 2016
During the conference I spoke with many people carrying various Architect titles. Interestingly many came from many larger organisations and government agencies, which shouldn’t have been any surprise given the history of the conference. I remember meeting and speaking with one particular Enterprise Architect (EA), who seemed to be one of the most pragmatic EAs I’d met, who was trying at all costs to stop his board randomly signing large contracts with product vendors like Oracle and IBM without the proper diligence about understanding what they were actually building.
At the same time, I met a number of architects struggling to help their organisations see the value of architecture and the role of the architect.My talk
I spoke after Booch’s initial keynote, “Architecting for the Unknown” which lead really well onto the topic I was speaking on, “Evolutionary Architecture“. I had a packed room as was a topic that resonated with people. At one point the conference organised brought more chairs into the room and there was still only standing room for the 90 minute talk! I had some great questions and conversations throughout and found out later that I won the award for the best conference talk in the “Architecture in Practice” category!SATURN Evolutionary Architecture talk audience
I’d definitely recommend attending SATURN if you’re interested in focused on building architectural thinking and an opportunity to connect with architects across the industry. The size is great for conversations, sharing experiences and with next year’s scheduled for Colorado will be really interesting too.Final thanks
I’d like to thank the organising group calling out Michele Falce (Technical Event Coordinator), Bill Pollak (General Chair), Jørn Ølmheim and Amine Chigani (Technial Co-Chairs) who did a great job putting together a fantastic conference, John Klein for hosting Office Hours, and Michael Keeling for organising an invite for me.
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
- Sponsored: 64% off Code Black Drone with HD Camera
Our #1 Best-Selling Drone--Meet the Dark Night of the Sky!
My name is Andy Hoover and I manage our Customer Support operations here at LeanKit. I spend...
The post How Integrating Zendesk with LeanKit Changed Customer Support appeared first on Blog | LeanKit.
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).
At this year’s Global Scrum Gathering in Orlando, SolutionsIQ President John Rudd and I presented on the topic of Agile portfolio management. During our presentation, Andreas Schliep (long time Certified Scrum Trainer, Agilist, and hilariously dry-witted guy based in Germany) tweeted,
“Brent Barton and John Rudd gave the term business agility a useful meaning. Think portfolio.”What is Business Agility?
Prior to the presentation, Andreas told me how concerned he was with the term “business agility” because it lacks meaning and can water down a company’s ability to derive the real benefits from being “Agile”. Luckily for Andreas and many people attending our session who were uncertain about what exactly business agility is, thinking about it from a portfolio perspective provided a pragmatic way for business to support a modern organization. Now I’d like to share here what we shared to participants that day.
Simply put, business agility means leveraging iterative delivery capability and actively managing organizational investments. The bottom line is that, if we do not align our portfolio practices to leverage what Agile has to offer, we miss out on opportunities to maximize returns and adjust plans.
The rest of this blog is dedicated to “thinking portfolio” and one of its most important components: Return on Team.What is Return on Team?
Return on Team aligns today’s needs for planning and budgeting. It is a better and simpler way to manage a portfolio. In many ways, small (<10 people), dedicated, persistent, cross-functional, empowered, self-organizing teams are at the core of Agile. This structure is best for knowledge workers who solve today’s complex problems like software solutions. Rather than dissolving teams (in particular high-performance teams) and incurring the unnecessary overhead of reintegrating individuals, we can think of these teams as assets. Further, establish these dedicated and persistent teams as enduring corporate assets. Then like tracking return on an asset, we plan and track Return on Team.
Consider an airplane. Notice that in the previous sentence, I said “an airplane” indicating that it is a concise unit by itself. But you could, as engineers may, consider the entire vessel a collection of many integrated parts that operate in concert to produce the value that airline customers seek (i.e., flying from point A to point B). It seems ridiculous to think about a single airplane as a bunch of constituent parts–and yet this is precisely how we think about individual team members on a team. The team is an airplane: the individual parts (team members) collaborate and coordinate to deliver the value that end-users seek, whether that’s software or something else. When you have a high-performing team, the last thing you want is to break them up just when they’ve achieved velocity–probably for the same reason you wouldn’t dismantle an airplane midflight. But just like you can move an airplane from one hangar to another (even when it isn’t carrying passengers), you can reassign a team from one initiative to another one. Your teams are enduring corporate assets, like a fleet of airplanes. Once they’ve hit their stride and produced consistent value quickly, you can actually plan and track accordingly. That is the combined power of Return on Team and active (Agile) portfolio management.
The team is an airplane: the individual parts (team members) collaborate and coordinate to deliver the value that end-users seek.
Return on Team allows planners to match supply (team capacity) to demand in a data-driven manner. This simplifies the process by an order of magnitude and prevents us from accidentally pulling people off one team only to re-form another and incur transition costs. Also, we have better data as a result. When a system does not change, history is the best indicator of future performance. By keeping teams persistent, we can use historical data to plan more realistically.How Do You Measure Return on Team?
There are two ways to measure Return on Team: trend and performance against plan. Since persistent and dedicated teams focus on a common delivery stream, relative contribution to a corporate endeavor is easy to measure. Also, teams tend to get better at estimating over time. Costs are more stable, so they can be calculated simply. For example: one team costs $25,000 per week. Thus, if a piece of work is budgeted at $300,000, the team has 12 weeks to finish the work before the budget is exhausted. If it is a stable team, we can use previous trends to calibrate likelihood of a good outcome very early. Regardless how an organization calculates benefits (and expected benefits), the denominator of the basic benefit/cost ratio is very simple and maps into team’s work without friction. The result is greater predictability and thus reduced risk, with the ability to move away from investments that are not showing benefit.
Finally, most of the work teams do is based on investments much longer term than a year, except when the organization is in search of new potential long term investments. Thus, in order to support short term business commitments against long-term investments, we need to become good at developing short-term initiatives (often about a quarter in length) so we can course correct without as much gnashing of teeth. These short term-initiatives can be estimated in comparable team units which we call a team iteration. Now, we have units of supply that we can match to demand with short-term outcomes derived from long-term commitments. From this, we can base our decisions from the perspective of Return on Team.Summary
In review, persistent and dedicated teams, as corporate enduring assets, delivering increments of customer value every iteration cycle with a predictability that portfolio managers can use to plan short-term initiatives that drive toward long-term investments–that is the ultimate goal of business agility. The Agile business can plan with a greater level of confidence and predictability and reduced level of risk.
To learn more about Return on Team and business agility, check out Brent’s webinar “Agile Portfolio Management: Adapting to Changing Priorities”!Watch Now
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.
Targetprocess v.3.8.7: IMAP protocol support for Inbound Email Integration, added Effort units to Project Customize Cards, bug fixes
Believe it or not, we have finally added the ability to use IMAP protocol.
Basically, this means two things:
- You can now use more modern protocol for your Inbound Email Integration plugin. Your IT guys will be happy to hear that. If you missed out on the ability to turn incoming emails into requests because your infrastructure does not allow for obsolete POP3 protocol, then now is the right time to try it out.
- There's hope for every feature in the backlog, no matter how long the wait.
You can now add units for Total Effort and EffortToDo/Total Effort to your Project cards from the Customize Cards tab. This will make it easier to get a quick overview of Effort for your Projects.
- Fixed a problem with card hang-up during drag and drop on a board
- Fixed an issue with the display of inactive users for People units on Projects and Teams cards
- Fixed a case where 'auto-assign' would not work when assigning People from a Team to a Project
- Fixed 'show more' functionality in the list of work items for a Person
- Fixed inability to edit Time description from the Time tab of an entity
- Fixed a problem with remaining cards selection after a batch move
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.