Recently, we've seen a lot of activity in the marketplace focused on "scaling Agile." It seems after a decade or so, people have been willing to admit the "Scrum of Scrums" concept just wasn't cutting it. There is now sufficient evidence of large scale failed Agile transition initiatives to know that previous decade's hypothesis about delivering large scale Agile adoption hasn't worked. Now we have a new wave. IBM has DAD (Disciplined Agile Delivery) and Dean Leffingwell and Rally Software Development have SAFe (Scaled Agile Framework). Other tool vendors in the market are encouraging emergence of "me too" scaled Agile solutions.
Those who’ve worked with us at Sprint.ly - as customers, colleagues, and partners - know that we’re committed to our craft. We enjoy pushing the envelope on UI/UX, development methodologies, and technology. At times, this has meant needing to pull in specialists who are working at the very edges of their field to help us deliver. This is how we met Sam Breed and the Quick Left team in Boulder, CO.
Sam is a core contributor to Backbone, which lays at the foundation of our frontend architecture. His contributions to our recent performance refactor have dramatically improved the responsiveness of our application. After completing this project, two things were clear to me:
Sam and the Quick Left team are consummate craftspeople. Delivering quality code and actionable advice took precedence over their bottom line.
I wanted to spend more time working with Sam and the Quick Left team.
Sadly, I couldn’t recruit Sam and he couldn’t recruit me. This mutually sad realization, coupled with Sam’s confession that Quick Left was keen to start building their own products, led me to invite Sam out for beers.
I had an ulterior motive, though, which was to propose that we combine Quick Left’s chocolate with Sprint.ly’s peanut butter. We were building a great product, which Quick Left and their clients used, and Quick Left had an enormous engineering team ready to be aimed at the treasure trove of products swirling through our collective brains.
When our CSO, Matthew Work, first heard the idea he said simply, “That’d work.” Matt’s background at Pivotal Labs running Pivotal Tracker gave him great context to see that this symbiotic relationship had real potential.
Today I’m enormously proud, and exceedingly humbled, to announce that this potential has been realized. Sprint.ly and Quick Left are now one. We will operate offices in San Francisco, Portland, and Boulder. Our mission is to deliver great products - our own and our service customers’ - using the very best technologies and development methodologies available.
Wow. I am excite. Much coding ahead.
P.S. You can read more about this awesome news, along with FAQs, on our homepage.
It is really, really hard to design getting started experience in a tool. We’ve had many iterations and improvements, but still are not happy with the current implementation. So we’ve started from scratch and want to improve the existing experience in Targetprocess.
It is always interesting to explore how other vendors solve similar problems. This post is a quick summary of getting started experience in 15 (mostly project management) tools.1. Salesforce
Salesforce shows you a Getting Started page with several videos. This is it. Videos are quite lengthy and you have to spend about 30 minutes on watching them. It is interesting that such a sophisticated tool like Salesforce solves getting started problem with videos only.2. Trello
Trello is a super-lightweight tool for project collaboration. It’s based on an idea to create many boards and manage them. First board is actually a getting started board where you will read about all the features. It cleverly has 3 columns: Basic, Intermediate and Advanced features. If you open all these cards and actually do what they say you have a good understanding of a tool and know how to use it. Great implementation.3. Asana
Asana is similar to Trello, but much more complex (I personally don’t like it). Getting started experience is more detailed as well. First, you see a short video that actually explains a little. Video is on a separate page and it’s hard to miss it. Then you have a 3-steps wizard to define your identity, invite team members and create a team. It is quite handy and well designed. Finally, you dive into the tool. UI is loaded with many buttons and panels. The only help you have is “Videos” section at the bottom. Still Asana has a style and looks modern.4. Plan.io
Plan.io meets you with a wizard that guides you through the system. I liked it initially, but in a minute I got frustrated with too many steps. Then it became really annoying. Huge texts in popovers are not welcome to read, so I skipped them and learnt a little. And “Something is still missing” message drove me nuts in the end.5. Clarizen
Clarizen is a feature-rich project management tool. Initial wizard is OK, but I have had some “Hmm…” moments during project type selection. Then you see another wizard that shows you a 6-min video and obvious navigation panel. The tool looks heavy, with many controls and screens. It doesn’t feel hard to grasp though.6. Basecamp
Basecamp is a famous light-weight coordination software. It’s very simple. First, you see a bright welcome message. There are similar bright messages in new areas you visit, which is good. Sample project describes real features in Basecamp, so you can explore UI and learn something about the tool at the same time. Interestingly, I like Trello’s implementation of this idea more. Not sure why.7. Wrike
Before you start, you have to lie about your phone number (I’ll never understand why this field is required). Then you see a several steps wizard. While some steps make sense, I don’t think that “Assign task via email” is so important to have here. It is not so clear how to complete this Welcome Quest, I had to think a bit to find out why some steps are still there. Also Skip link is hard to find. Maybe it is intentional, but such solution has its flaws. There are several areas on top and when you put the mouse over an area icon you see a popover with a video. Quite a clever idea, but the implementation is annoying. Maybe it is good to hide these videos at some point.8. 5pm
In this traditional project management tool you see just 2 help messages after login — and this is it. Minimal effort in getting started design. I am not convinced the tool is simple enough to handle the getting started experience that way.9. Moovia
You immediately see a news feed with product updates. Maybe it is better to show a feed with product usage tips. So there is no getting started design at all.10. Redbooth
The welcome message you see is irrelevant and too lengthy. Similarly to Trello, there is a ToDo list that describes the tool itself. Empty areas helps you to make a correct action, like add a Task. System shows you good tips in the right moments. I’d say getting started in Redbooth is well-designed and usability is great.11. TeamLab
TeamLab looks complex. Right after the registration you see a video and wait while your account is being created. Good use of waiting time! Then you start a project and see three(!) yellow messages right away: one about Android app, another about email activation and the last one is a getting started wizard. Too many for me. The wizard is very short with just four steps. The system gives prompts to some actions when you navigate to a new screen, which is very handy. Help is built-in, so you don’t navigate away when you want to learn something. Quite good.12. Yodiz
This is an agile project management software. It meets you with a video (too small) and a project setup wizard. UI is not stylish for sure — too many colors, various icons and overall impression is not great. Large bright buttons with actions in empty areas are good though. The tool was easy to grasp, but I’m a domain expert :)13. Jira
Jira’s getting started experience is similar to Salesforce — it is very basic. You have a dashboard component with Getting Started steps. Small wizards are nice. Service Desk area is different and shows you quite many popovers. I got lost with them, in fact.14. TeamPulse
This agile project management tool shows you a 6-step wizard that describes main UI areas. That is it.15. TargetProcess
Targetprocess is not an easy tool. It is really flexible and has a new UI-paradigm, so we wanted to show people how to use it properly. First, you select a process to start with. Then you see a 3-minute video that explains a concept and main ideas. Then you jump into a wizard. We put significant effort into the wizard and I should say it is the most clever implementation I’ve ever seen. But it seems the wizard is very long with too many actions and steps. We have stats here. Around 70% of people abandon the wizard after step 2. It means 70% of people learn nothing from it. And even the pulsating blue dot doesn’t help to grab their attention.Summary
Let’s summarize the most popular approaches to getting started. Most show a video and provide easy access to more videos about a product (Asana, Yodiz, Targetprocess). Several tools use the tool itself to design ToDo with getting started actions (Trello, Basecamp, Asana, RedBooth). Some tools have UI wizards (TeamPulse, Targetprocess, Clarizen). RedBooth tries to give guidance to users in a good way, I think. Nothing novel, for sure.
I personally think that a long wizard doesn’t work and most people just skip it. Also it is required to unblock as many paths as possible in user interactions. If a tool demands something at some point of time, there should be an obvious way to fulfil that demand. For example, if it’s not possible to add a user story without a project, there should be a clear way to add a new project right from the “Add user story” screen.
You’re in your first days as a product manager. In no time, your calendar is full and you have a zillion emails. There’s so much to do. Where to begin?
Before the demands of others overwhelm you, you need to prepare yourself to be the business and market liaison to the product team. Your role as a product manager or product owner is to make the best business decisions for the product, working from the best available information.Refresh your domain expertise
If you’ve been in your industry for years, you probably have strong domain expertise but you may not be up-to-date on the latest information.
Review the corporate pitch. Perhaps the fastest way to get up to speed on your company and its role in the industry is to review the product and corporate slide decks. Whether your company is a bellwether in the industry or on the periphery, what’s been said in the past will help you understand how your company and its products are perceived, at least from the perspective of your new organization.
Catch up on the latest blogs and articles. Take time to review the latest thinking in your industry. And even if you’ve been in the domain for years, it’s always helpful to take a new look from your new perspective as a product leader. Reports from industry analysts may reveal new industry trends, and perhaps show how your company and products are influencing them.Fill out your technical expertise
You may have some familiarity with the product from your past research. Now it’s time to get into the raw details.
Know your new product. What documentation exists for your product? You can probably find some customer documentation and help screens, release notes, product plans, sales and conference presentations, white papers and ebooks, and sales enablement tools. Review them all. Learn the key capabilities, particularly those that are competitive differentiators.
Review the product roadmap. And where is the product headed? Has anyone developed a roadmap for the next few releases? How does what you’re seeing align with what you know about the domain and industry?
Understand the architectural themes and challenges. Talk to the developers about the technical challenges for the product. What percentage of development effort is spent on architecture and defects versus new functionality? And while you’re at it, interview the developers about their perspective on your role in moving the product forward.Update your market expertise
You likely have some market expertise but it never hurts to give yourself a refresh.
Sit in on some customer support calls. Want to know what’s going on with your product in the field? Ask customer support. They know about technical problems with the product as well as customer implementation problems. Sit in on some support calls and listen to customers directly.
Go on some sales calls. It’s fascinating to examine the contrast between the product as perceived by the product team and by the people in the field. When you’re on a customer visit with your sales team, you’ll hear how the product is being sold—right or wrong. You’ll also hear unfiltered customers’ problems in their own voices. Listen to the language they use; listen to the problems they’re trying to solve. You’ll get plenty of ideas for how to improve the selling and promotion of your products. And you’ll get to know some sales people in a more social setting; they’ll be your contacts in the future when you need advice on sales enablement and product improvements.
Do some installation/implementation visits. For enterprise products, implementation is where all your sales and marketing promises meet the real world. Watch (or help) the implementation teams install the product; sit in on any customer training; examine closely the areas where the product must be configured or customized to work in the customer environment. You’ll definitely get some great ideas on improving the product.
Eventually, you’ll want to start visiting customers without a selling or support objective but get these initial customer touchpoints under your belt first.Leverage your process expertise
Now that you have a strong understanding of the technology, industry, and domain, take a look at your internal product processes. What methods are used in your organization? Where are the company templates stored? And which of your favorite processes apply to your new situation?
Evaluate existing processes and systems. If you’re stepping into an existing job, you’ll likely find a set of methods that are already in place, formally or not. If you’re part of a new product management team, you’ll want to be a driver in defining your product processes.
What artifacts are necessary? What minimal set ensures success? Is your organization clear on what constitutes a requirement and what’s actually a specification? Which positioning technique is used, if any?
Start your own product playbook. Take all your methods and the company’s methods and put together a set of living documents. You’ll want your product plan and financials, buyer and user profiles, positioning, requirements, maybe a price list or pricing model, and any other documents that you reference often. Print them or store them in your dropbox so you’ll have them handy. For more on the product playbook idea, see http://appliedproductplaybook.comWhat should product managers do in their first days?
Look for high-impact deliverables that don’t require much up-front effort. Train the sales engineers and product implementation team. Develop informal product champions. Refresh or refine your product positioning, taglines, and blurbs so you can do “copy-and-paste marketing.”
Then focus on the methods to make sure you have a minimal set of effective processes that ensure product success.
What tips do you recommend? Add your thoughts in the comments area.
When it needed to scale the size of its delivery teams and improve its time-to-market, Telstra -- Australia’s leading provider of mobile devices, home phones, and broadband Internet -- jumped right into Agile. At a fundamental level, the Telstra story is about moving from Agile projects with just a few people to Agile programs with hundreds of people working on many different things.
Telstra started its Agile journey with five "wagile" teams, working on four projects in a mixed Agile/waterfall environment. It scaled up to 7 fully Agile teams, working on 24 concurrent projects under a single Agile Release Train, by applying Dean Leffingwell's Scaled Agile Framework® (SAFe.) SAFe gets a lot of attention in the Agile community, but at Telstra it became much more than a buzzword or strategy. SAFe helped this large telecommunications and mobile organisation transform its Enterprise Data Warehouse (EDW) practices and shape an Agile organizational culture -- all in a matter of months.
Telsta's results speak for themselves:
- Average delivery cycle time down from 12 month to 3 months
- 6x increase in delivery frequency
- 50% reduction in cost-to-deliver
- 95% decrease in product defects
- 100% of projects delivered on time and on budget
- Happy project sponsors
- Happy teams
I recently attended Dan North’s Accelerate Agile course. One of the things he talked about was why measuring productivity is such a terrible idea in software. Although I’ve always known this in my gut, I really enjoyed Dan’s explanation. I think it made the kind of sense that would appeal to people who traditionally think this metric is a good idea. So here’s my recollection of his explanation.
Let’s start by looking at productivity. Wikipedia has the following to say about productivity:
Productivity is the ratio of output to inputs in production; it is an average measure of the efficiency of production. Efficiency of production means production’s capability to create incomes which is measured by the formula real output value minus real input value.
That’s a lot of words I know, but what is important is ‘capability to create incomes’. The word productivity comes from the industrial era of production lines, where more productivity, meant more products, which meant you could sell more, and therefore create more income. So for factories: more productivity usually means more income. Great, why wouldn’t we measure something that is clearly a leading indicator for revenue?
Well, revenue in software is not related to the number of units produced. In fact I can sell the same bit of software several times and make lots of income without producing more software. The digital nature of software means that income is no longer related to productivity.
Okay but wait if we can sell a piece of software 1000 times for each bit of it we produce, then surely we can sell each bit we produce 1000 times, and productivity is still good?
Well lets consider if software is an asset or liability. Consider a problem you have in your business that needs to be solved. Imagine you could solve it with a large enterprise piece of software, lets say SAP. But you could also solve the problem with a small piece of software that does only what you need. Given the options which of these two systems would you rather manage. I imagine most of you would rather manage something small and simple.
Now imagine you could solve the same business problem without software. Would you rather manage the solution with some software or the one with no software? Again I’m gonna imagine that the no software solution looks pretty appealing assuming it solves the problem as well as the software would solve it.
So what does this mean? Well it means that large software systems are harder to manage, take more time and effort to do so, and all things being equally we would all prefer less software to solve our problems. Thinking like this helps you see that software is in fact a liability.
Now let’s go back to that productivity measurement. If productivity measures how much stuff we create, and software is a liability, then measuring productivity in software is essentially the same as measuring the rate at which we are accumulating liabilities. We already know that for software more units do not equal more income.
So if productivity goes up, then liabilities go up and income remains the same….
Does that sound like a good business model to you?
In fact doesn’t it suggest you should send your developers to the beach?
Go on, send them to the beach for today. I guarantee it will not lead to a loss of income. In fact it might just be the start of something interesting
In a future post I’ll explain what Dan recommends as a better metric for software instead, so stay tuned.
When teams start doing agile, one of the first impediments they usually run into is the inability to complete stories quickly. In Scrum that can result in stories spilling over sprint boundaries, whereas in Kanban in results in really long cycle times.
Do you have this problem?Here are five ways to complete user stories faster
- Have smaller user stories: When you have smaller stories, developers finish stories earlier and testers can start testing them early. This way, testers dont get a big story to test later on. So, think hard about whether the stories can be further decomposed into smaller stories.
- Multiple developers work on the same user story: Don’t assume that only one person can work on a story. Look at your tasks and see if different developers can work on different tasks of the same story, so that it will be completed earlier. Also, dont assume that only a single person should work on a task. Sometimes it is helpful to pair multiple team members together to work on a single task.
- Automate some functional tests: When developers work on the development, testers can write automated functional test scripts during that time. Once development is complete, the actual testing time is reduced because you can just run the automated tests instead of manually executing each test case. As a bonus, over time you the improve the automated regression suite.
- Multi-skilling: Testers helping with simple coding tasks, and developers helping with test case execution are two ways multi-skilled teams work better. See how you can bring this capability in your teams.
- Co-located teams: You will be surprised how much time can be lost in communication between team members who are not co-located. Emails going back and forth over a period of two or three days is a big waste of time. By seating the developers and testers next to each other, a lot of wasted communication time is saved, and more can be completed.
Not all the above approaches are suitable for every team or every situation. The team needs to look at all available options and decide which is the best way for them.
Imagine entering a bazaar where all your questions are answered by experts with wide ranging perspective, beliefs and experiences.
Think of being transformed by the learnings, exchanges, debates and discussions.
This defines the Open Space experience.
If you’ve never been part of an Open Space, I’d like to invite you to break the ice at Agile Open Northwest from February 5th – 7th in Seattle, Washington.
Been around Open Space before? Then this event’s for you. You’ll fit right in amongst some of the sharpest and brightest minds from the Pacific Northwest. This year’s event, titled “Agile – Harder Than It Looks,” brings you face to face with some of the toughest challenges facing your teams and organizations.
Here are just a few of the questions that might be tossed, turned and flipped outside down over the course of the 3-day event:
- What is the difference between Lean, Scrum, XP and other agile approaches?
- What new technical challenges face agile professionals?
- What are the latest cutting-edge developments in the agile software development world?
- How do agile frameworks and methods co-exist with project management, process control and other governance structures?
VersionOne is a proud sponsor of this event; we are thrilled to once again support the passionate agile community of the Pacific Northwest.
The event is sold out (not a surprise!), but place your name on the wait list for a possible chance to score a ticket.
Thank you Agile Open Northwest for giving VersionOne a wonderful outlet to connect with the Agile community. Pacific Northwest Agile community: you are fortunate to have this opportunity again for 2014.
Don’t miss Agile Open Northwest.
Community Marketing Manager
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
I’m facilitating a certified scrum product owner workshop today. We talked a lot about how to give product requirements guidance to the scrum team. Then I shared this video.
I must have missed this bug… I made this fatal commit to the production branch… The rollback didn’t save the release… Growth metrics are 50% less than expected…
That’s how approximately the hierarchy of epic fails is lined up in any IT company. On each and every level, people experience their own mini epic-fails, if the fail is perceived as such at the top of the organizational pyramid, starting the vortex of blame that rolls back to the bottom. The fail mentality then grows into the roadblocks that stand in the way of major goals, and makes people approach organizational challenges not with the mindset of accomplishing things, but with something like: “It must be my personal epic fail. I’m to blame. But.. it’s not only me. That’s how things are tied up. Anyway, how do I personally cope with it? How do I excuse myself, to push this blame vortex away somewhere?” Once this thinking sets in, it means doom.
The truth is, those mini epic-fails are the wrong ones. The real epic fail would occur if people on all those levels were incompetent at their job, and hence shouldn’t have been hired at all. It’s someone’s job to set meaningful goals for competent employees and hold them accountable for results as opposed to the false goal of making them feel it’s their epic fail. Is it at all productive to set on figuring out where the single point of epic fail is? The chain goes like that: anyone in a higher position of power has not enough space inside of them to process the alleged epic fail, and instinctively looks to turn it reverse, into the outward direction. Then the ball can be kicked endlessly.
Here’s one example of such a wrong epic fail. Steve Ballmer, who is one foot out of the door from Microsoft confessed in his exit interview that the real reason behind his resign was being pushed too hard by the board to enact the organizational changes in the company. Apparently, Steve blamed himself on being too slow in running the changes. He saw this as his own epic fail, questioning his own ability to be a successful change agent. The board didn’t see themselves committing an epic fail as they ambushed the professional, who was amid of doing his job, to quit. Now, who will find out if the changes that would have gone with their pace as intended by Ballmer will have evolved into meaningful results in their due time? The effect is quite the opposite as the board now needs another CEO, and the so much sought after “change” — whatever their definition of that is — will not happen for even longer, as they wouldn’t let Ballmer follow through on his job. Who is now incompetent: the board or Ballmer? Considering that Microsoft is now targeting consumer electronics, the question might be if that’s the right direction at all, the one that they have chosen, maybe that’s where the epic fail is hiding?
The hardest part of getting started with visual management can be figuring out your workflow process. If you’ve never tried visual management before, terms like ‘value stream’ and ‘mapping your workflow’ can sound quite intimidating. So let’s rewind and go over the basics. Visual management is based on the principles of Kanban. Step one for […]
The post Getting Started with Visual Management: Mapping Your Workflow appeared first on Blog | LeanKit.
In a previous blog, I discussed ways to make distributed daily scrum meetings more effective. This blog reinforces those ideas and provides additional tips to run successful scrum meetings with geographically distributed teams.
Productive, timely, 15-minute Daily Scrum meetings, remain a challenge. As many practitioners will attest, co-located Daily Scrum meetings are nearly as challenging for some of the same reasons:
- Meetings go beyond 15 minutes
- Not everyone has a chance to be heard
- Conversations wander into resolutions and opinion
- Impediments are not captured and addressed
- Others interrupt
Holding team meetings where members are not in the same physical or mental space is quite challenging, and it becomes more so when the team is geographically distributed. As I mentioned previously, the initial rule of thumb was to breakdown the daily meeting into small deliverables and then focus on each part of the meeting. The overall Definition of Done is the teams take ownership of the Daily Scrum meeting and use this as a foundation/basis. This idea has evolved into a goal for Daily Scrum meetings of having the team take ownership and management of their daily meeting. With this, we can create “Definitions of Done” for each part of the meeting.
Part 1: The team listens to each other’s ‘questions 3’ with no interruptions.
- Definition of Done: each team member has an equal voice to state their answers and be heard by their team members.
Part 2: The ScrumMaster reads the impediments/issues they recorded and the team adds, corrects and confirms the list is correct
- Definition of Done: the ScrumMaster reads off the impediments and has the team approve them
Part 3: The participants in the Daily Scrum meeting organize additional conversations around the Sprint and the results of the Daily Scrum Meeting the team.
- Definition of Done: the team members self-organize and work on the issues at hand and have these groups communicate what they did before the next scrum meeting, to the rest of the team.
When it comes to implementation there‘s a way to execute this process. For example:.
The meeting begins with one team member (initially the ScrumMaster) asking a team member the ‘questions 3’.
- The team member identifies the task and the story they are working on. They describe at a high level what they are doing and how much more time they need to finish.
- The team member then describes what they plan on doing tomorrow. If they will be moving to a new task, they should state which task.
- The team member then states what issues/impediments/ concerns they have about getting the work done or completing the sprint..
- Team member #1 then asks another team member the ‘questions 3’. This is a sure way to transfer ownership of the meeting to the team.
This is not a ritual. It is a basic pattern of action that can be used to start off a new team, orient new team members and get a team back into a rhythm. I have found that getting back on track is a lot easier if there is a simple base or foundation to structure and define roles. From there, teams can quickly self-organize…and it works well when things get stressful!
Roles and Actions for the Daily Scrum
ScrumMasters don’t run the Daily Scrum – they guide the team to run it themselves. Their primary focus is to collect the impediment list and get it approved by the Team. There should be a task on the task board regarding impediments for reporting the status of impediments.
Team Members individually and collectively run the meeting.
The Product Owner should be there listening and ready to answer questions immediately after the meeting closes.
Anyone who has committed to deliver something to the team during the Sprint must have a task on the task board and attend and answer the questions 3. This includes Product Owners, stakeholders, and management.
Guidelines and Techniques for the Daily Scrum
1) Turn the meeting ownership over to the team by having each team member ask another member the ‘questions 3’. Since there is no pattern or set order when one team member asks another, people on phones pay attention because they do not know when the questions will come their way.
2) The ScrumMaster is the servant leader, helping the team stay focused on the conversation, the task board, and the questions. It’s surprising how quickly the rest of the team picks up on this focus and brings the more loquacious and “off tangent” teammates back on track by asking “what task are you talking about?” Some teams go as far as including a protocol statement in their team charter stating all questions in the daily Scrum meeting begin with the user story and the task.
3) At the end of the first part of the meeting, the ScrumMaster, who may have been taking notes on the impediments, begins the second portion of the meeting by going over the impediment list to see if any were missed. This action reinforces that this meeting is for the team and that all issues are visible and noted.
4) The third and final part is a call for the issues to be discussed immediately after the meeting. Any team member, including the Product Owner may ask for conversations on story or task issues.
5) As soon as that is sorted out, the ScrumMaster requests that all decisions resulting from the upcoming conversations be communicated before the next daily meeting.
6) The daily meeting is closed and the conversations continue.
I watched this youtube clip a while back. It’s all about a speed painter. Go watch it quickly, it takes 3 minutes, and check your feelings whilst he is painting.
I initially though “WTF?” I don’t recognise anything, and by the looks on the judges faces that’s what they were thinking as well. In the last second, he turns the painting upside down and reveals that it’s a face. Everyone is awed and amazed (me included) and stands up clapping.
Once the painting is recognisable, I was impressed. But the same brush strokes upside down just left me confused and unimpressed. Was this just because it wasn’t something I recognised? This got me thinking.
How many things in life am I unimpressed with, just because I don’t recognise them ? How many things do I shut out or ignore because I don’t value them? Am I going through life wearing coloured lenses? Or blinders?
The next time I am faced with something a little weird and I don’t get it, I’m going to pause and spend some time trying to understand what the magic is. There must be magic if someone values it enough to share it with me.
In one of my previous articles (Project Managers: Nurturing vs. Hiring?) I’ve written on why we prefer to nurture product owners (we call them feature owners) internally, instead of hiring newcomers. Quite some time has passed since we decided to try this approach, and it has yielded good results mostly. It’s safer and more reasonable to have several competent people involved in the product-related decision-making, instead of one person who is held accountable for everything. All the people in our company — QA’s, developers, designers, marketing and support people — are engaged in educational activities one way or another. These activities are always intertwined with work. Home-made product owners are educated with the work, too, and we’ve come up with some sort of syllabus for them. This syllabus emerged from the real-life needs; it is a composite of skills and knowledge actually required to manage our product.
We are not putting a “certified Targetprocess Product Owner’s” training course tag on that syllabus, but I intend to write a series of articles that would provide some sort of “homeschooling” for novice product owners. Quite often formal training courses are too brief (2-3 days), cost money and fail to give that universal knowledge that a product owner needs (poke me if that’s not true). A formal course might be limited to a single “brand” or “label” from a certain domain, while the needs of practical software development require out-of-the-box, labelless thinking. That being said, a product owner still will want to be familiar with the major trends in the agile domain, and to switch between the brands and labels easily, depending on where a product is meant to go next.
Here’s a summary of this homeschooling Product Owner’s Syllabus. The mind map only gives a descriptive outline of the syllabus, as an intro to the upcoming articles. Click to enlarge:
We educate our feature owners in the 4 main areas: Agile Domain, Marketing, Product Development and Backlog Management. Targetprocess 3, our visual project management tool, is the practice material for these studies.
Let me re-iterate, that first and foremost a Product Owner is someone with a curious and agile mind. The way we orient our feature owners/product owners is free from prescriptions. The main disadvantage of taking a training course that bears some “label” would often mean that students are pushed to operate within the limits of this label forgetting that there are other practices that can work better in this particular case. As an example, if there’s a course that trains Product Owners in Scrum only, this will be limiting, because their work might demand switching to Kanban, or maybe to Multiban, or to waterfall (which is now clad in the toga of SAFe). This freedom from frameworks and labels is the most important prerequisite of a product owner’s success. Practices are only practices. The first question that a product owner should ask when introduced to a technique or a practice is: “What problem does this practice solve?” and not: “How do we tweak our product development to fit it to this agile practice?”
Another meta-skill applicable to all the areas is the ability to measure, analyze and make decisions. We measure feedback, we measure customer satisfaction, we measure the value of features. Most decisions are made based on the measurements and their analysis. The upper tier of product-related decisions (which feature will be developed next) is done by a group, the product board, and feature owners are a part of this board. Then, decisions related to a product feature are in the realm of power of a feature owner. The air of learning and sharing is maintained throughout the whole product management process.
That’s how it looks, for starters. I will cover the subjects included to this syllabus in more detail in the future articles.
The Scrum team’s way of working is based upon the values of Focus, Openness, Commitment, Respect (for self and others) and Courage.
For this blog post, I’m going to dive into that last value a bit more because I think it often gets overlooked… courage.
Image credit: Cottage 960
What does this really mean? How can someone in IT be courageous? That’s just for folks in the military, firefighters or police officers, you might say.
Not so, I say.
A few scenarios might help.
Scenario 1 – I’m the Product Owner for a mission-critical agile project. The CEO of the company comes directly to me and says he wants the team to add another feature into our current Sprint. Says he needs it ‘ASAP.’ This feature is useful and needed. It makes sense to do it, but it’s not a small demand. The team is making good progress on the current sprint and only has 4 more workdays before they deliver the agreed upon functionality for the 2-week sprint. Would you simply say ‘Yes’ because he’s the CEO, or would you delve a bit deeper into the current status of the project/sprint and the priority of your Product & Release Backlogs, explaining to him that stopping a sprint-in-progress could have a larger impact, and what that might be? Clearly, this takes courage.
Scenario 2 – I’m the Manager of the newly created Agile PMO. I report directly to the VP of IT. She’s a reports junkie; she likes to see a lot of ‘em, and at many different levels. She also likes to have me deliver these reports verbally and via email to several different groups of folks in the organization. She changes her mind a lot on what she wants to see, too. I spend an inordinate amount of time doing this reporting and delivery, which I believe should not take up this much of my time every week. I have many other important items to tend to, as the organization is in the midst of an agile adoption and transformation effort. Do I have the courage to set up a conversation with her and explore her motives, exploring new ways of disseminating information, explaining the impact this current situation is having on my many other demands? This takes courage.
Scenario 3 – I’m a Team Member on an agile team. My forte is writing Java code. But I can do almost anything, or at least am willing to try/learn. If I finish up the tasks I signed up for in the current sprint, I ask around if anyone on the team needs help. If not, I get coffee, or give shoulder massages. But there’s one individual on the team who doesn’t have the same ‘All for one and one for all’ attitude that the rest of us do. Oftentimes, during the Daily Stand-Up meeting, he’ll report that he’s ‘got nothing,’ and looks to move on to the next person to answer his 3 questions. He doesn’t ask if he can help or learn how to do something; he doesn’t appear to be a team player. Do I have the courage to go to him and ask what’s wrong, or how I can help? And if that doesn’t work, do I have the courage to suggest that we remove him from the team?
And a few more questions of courage you could ask yourself…
Do I have the courage to try something completely outside of my comfort level?
Do I have the courage to be completely open?
Do I have the courage to throw away bad code I created, even late in development?
Do I have the courage to allow my direct reports to ‘self-organize?’
Do I have the courage to become less command-and-control and more collaborative?
Do I have the courage to give up my cubicle, and a bit of my privacy?
Do I have the courage to say I’m scared how this new way of working will impact me?
Do I have the courage to ask for help from someone junior to me?
What are some of the more courageous things you’ve done at work, and what impact did they have?
We have recently developed a new feature for having discussions about your board. This is an early release we want to get out to get some early feedback from our customers.
If you click Discuss at the top of your board, you will see all other members online at the present time and be able to chat with them.
Please let us know if you’d like to beta test this feature and help us polish it!
I’m often asked to differentiate product marketing from marketing (or marketing communications, if you prefer). This effort gets confusing for most because of the term “marketing.”
I’ve long been uncomfortable with the term “marketing.” For many of us, marketing is a philosophy. Marketing is looking at the business from the buyer’s point of view. It’s looking at the whole product, not just the software. Marketing includes packaging and pricing, and even how we answer the phone. But for others, “marketing” is a department, often associated primarily with advertising and branding.
Consider this: in marketing we use "greeking" to help people evaluate a design without getting distracted by (or obsessed with) the text. Product marketing owns the text; marketing owns the design.
For technology companies, product marketing managers are tasked with taking the product from the development team to the sales team and ultimately to the market. They are typically responsible for buyer profiles, positioning, and product information. Their focus is on product. In contrast, marketing (or marketing communications) is responsible for the execution of go-to-market programs. Their focus is on markets. They ensure programs are aligned with corporate branding standards, resonate with buyers, and empower the sales team.
It helps to think of marketing as a development organization. Product marketing managers bring requirements to marketing; marketing develops go-to-market solutions to address those requirements. Marketing is expert in designing programs that succeed and knows when to use those programs to address specific go-to-market problems.
As product manager is to development, product marketing manager is to marketing.
As a product manager brings requirements (or problems to solve) to development, product marketing managers bring go-to-market problems to solve.
A product marketing manager says, “The CIO needs to understand our infrastructure and architectural decisions to see how we align with their strategic technology direction.” Marketing replies, “We need a web page with a link to a white paper.”
Few organizations expect product managers to write production code. Likewise, product marketing managers should not develop programs, design brochures, or create web pages.
Product marketing identifies sales enablement PROBLEMS; Marketing designs SOLUTIONS.
How do you define product marketing? Add your comments below.
Related: See “Positioning, Messaging, and Ownership” at http://appliedframeworks.com/blog/2013/04/22/positioning-messaging-and-roles
Everyone knows the 99 Bottles of Beer song, and many programmers have rendered the loops of its lyrics into a programming language. There are countless pieces of code that feature the mesmerizing chant of 99 Bottles of Beer. Here’s the one in Python, for instance:
Judging by the count of programming languages that were used to convey this lyrics, software developers have some special kind of love for beer. I’m not a software developer, but I’ve been around many programmers who like to spend their late nights in the office with a slice of pizza and a bottle of beer nearby. Of all the drinks that humans can possibly allow in the office space, with the exception of coffee, beer is probably the most popular one, especially for late afternoons. It appears that beer has the quality that makes it a secret productivity booster, which is never advertised as such, but rather taken jokingly. Heh, you weird programmers, who can create something useful while drinking beer? That’s what an ordinary human might think.
Not so. Some programmers have a story that explains the power that beer has on them. I’m not ready to pull a “research” done by a super-reputable university out of my pocket, so I will tell what I’ve heard from a friend. This phenomenon is related to the agility of mind. For someone with a heightened brain activity (read, for someone with a curious and restless mind) having a beer quiets the brain exactly to such an extent as to allow transcending to this optimal flow that helps to shoot pieces of code and experience the state of immersion mixed with quiet enjoyment. After having this conversation, I’ve done some research and found a graph that seems to back up this theory (they call it “The Ballmer Curve“):
The point is: how much beer can one have until the programming skills deteriorate? For how many hours will this spike linger? From what I’ve heard, it can keep a beer-driven zealot shoot great code all night. The feeling is purely subjective. Some of the people I talked to use cognac instead of beer (that’s a more rare breed of programmers). It appears that programmers do not trust the pharmaceutical industry, because of the controversies associated with it. No energy booster pharma will ever make it right for people who write code. That’s a common sense logic, because how a drug company can possibly be motivated to come up with a pill that will bring this golden state of mind, focused and yet relaxed, to a software developer? Hmm, there might be some motivation, but anyway: pills are just plain boring. Taking a pill is not accompanied by this invigorating surge of a charged boost that comes with beer. Anyway. Some great Friday afternoon coding might still be in store for you… so how about go and get yourself a 6-pack of good beer? :)
There are some voices that urge to pay more attention to texts in user interfaces. I completely agree with Jonas Downey of 37 Signals who wrote the article “On Writing Interfaces Well“. Jonas argues that much attention is paid to graphic designs, while UI writing is neglected. Give me the shining armor and I’ll join the army of UI writers clashing with designers! However, there’s something more in this crusade against the overrated importance of the graphical bells and whistles, than emphasizing the challenges of writing for UI. It goes without saying that UI texts are the hardest to wordsmith, but I want to zoom out on clashes and challenges and focus on 2 basic meta-principles for UI writing. These principles are not only for writers. It’s designers who allow space for words, or make text bubbles removable, OR design smart action flows that are eligible for less writing.
Previously, I’ve written on how people learn to use products, and classified new users as Explorers, the Confiding and Give-Me-Someone-Live’s. A software product does not exist in a vacuum. The time when people are trying out a product or an app is the most crucial time of all. It can be compared to a mating ritual. If a product does manage to woo a new user, then they will marry and live happily together. But if the product will not do the woo, then all its great features will remain obscure and therefore unused. What can be more frustrating than working hard on a product feature only to find out that people do not actually use it because:
a) they don’t see why they might need it;
b) they don’t know how they should use it.
That’s where we approach the first meta-principle for writing user interfaces. Since people are always free to go away from a new software, and since most of them are Explorers, as per my classification, the screens in software product need to have a few words about the “why”. For instance, they can be put in boxes that a user will be able to hide forever (the “I don’t want to see this anymore” kind of thing).Principle #1. If a user is new to a product, “why” overrules “how to”
A short note with “why” has to be right in the screen. Here’s an example of the screen that lacks “why”. The 3 filters marked by purple arrows are really powerful, but this is not evident right away.
There are question marks, where a user can click hoping to get a clue on the “why”, but this will only open up a bubble with technical how-to’s:
A possible solution here would be to insert removable quick tips saying why those filters are helpful, and why people will want to use them.
On to the second principle. Product developers tend to be so immersed in their product, that they become blind to the flaws obvious to outsiders, or to some insiders who are not that soaped up. These developers often think that their user interface is very intuitive, and it requires no written instructions at all. That’s the case when the “why” is obvious but the “how to” is not explicit.Principle #2. If all’s OK with “why”, give a clear “how to” right in the screen
The screen below has a clear “why” (the looks of a card and how it appears on a board are customized based on personal preferences), and an explanation of the card sizes, but the how-to is missing. Nothing is said on how one is supposed to put together a custom layout for a card:
As an insider, I know that this is done by drag-and-drop, and someone who is exploring a screen with their mouse will likely have figured that out, too. But it’s psychologically more comforting, and less tiring to read a note that would say something like: “Use this box to search for the card elements. The list is too long to scroll. Then drag-and-drop these units to the card layout. Mind the sizes”. Then a shortcut will point to the info on which card size is recommended for what.
An example where “why”, “what for” and “how to” are balanced is shown in the next screen. The “why” is clear, because a user will want to configure her Prioritization settings for a board, and the radio buttons come with brief explanatory texts:
All the other principles, techniques and how-to’s for user interface writing can be derived from these 2 meta-principles. Writing for UI’s is a combination of language skills and ability to empathize with users, intermixed with the feel for design, and sky is the limit when wants to tell about the nuances of UI writing. However, no writing will save a product feature with an inconsistent “why” message and a cumbersome actions flow.