Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!
Software Development Blogs: Programming, Software Testing, Agile Project Management
Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!
This week I spent more time hangout out with people, which means less time is available for my blog. Sorry about that! (Also, I have a book to finish…)
Mind mapping is a technique for mapping information. A basic mind map typically emanates from a central topic with subdivisions branching out from that topic. The process for mind mapping has few basic rules and suggestions for constructing and formatting mind maps, which makes them highly flexible. Mind maps have a wide variety of uses based on one central theme: learning. The uses of mind maps include:
Once the starburst is created the map can be mined to establish major subdivisions and to indicate area where more research is needed. Walk through each entry and gather related items together. From the items you gather together, the name of the subdivision will emerge. For example, in our mind mapping mind map, when I gathered note taking, planning, research and other together the major subdivision titled â€śUsesâ€ť emerged.
Every Daily Process Thought essay begins using this type of mind map. Many people use the term brainstorming for this type of mind mapping activity.
Mind maps are tools for visualizing data. Seeing your thoughts put into patterns that represent how you think makes it easier to remember the ideas and concepts being mapped. Mind maps also help the mapper see gaps in the data or to jog creative thoughts by exposing relationships that do not jump out when processed linearly. Mind mapping is an extremely flexible tool, therefore there are an enormous number of uses. There is a saying that â€śif the only tool you have is a hammer, everything will look like a nail.â€ť Given the varied number of uses for mind maps, perhaps they might be an information-visualization Swiss Army knife.
What is your strategy for cross platform mobile development? It is a hard question to answer, because there are so many choices out there. In thie video, I talk about what I think about cross platform mobile development, define your options and give you my recommendation. So, if you are thinking about developing for iOS, […]
The post Cross Platform Mobile Development (iOS, Android, WP8) appeared first on Simple Programmer.
The right question for any suggested improvement, change, or suggesting weÂ stop doing thatÂ need to produce an answer to ...
Does this suggestion increase the probability of project success?
This means tracing the suggestion to the outcome of the project being better, faster, cheaper, or some other tangible measure of improvement.Â
What does project success look like?
The delivery of agreed-upon capability within established resource constriants, e.g. funding, schedule, facilities.
Five factors are used to assess the success
So Now What?
When we hear about something new, anything new, how can we test it that suggestion against business needs, mission needs, governance, or strategy. This starts with establishing the domain in which the suggestion might possibly work. Then proposing the framework in which it has worked or might work. Then a proposed way to assess the possible benefits of performing the sugegsted solution.
Mind mapping is a technique for mapping information using color, pictures, symbols and, most importantly, a branching structure emanating from a central concept. Tony Buzan in his book, The Mind Map Book, adds four characteristics to the definition that further define mind maps. They are:
I would add a fifth characteristic. Topics that are less important tend to be placed farther from the center image.
These five characteristics can be mined for rules to draw a mind map.
Here is an example of the use of images, words, colors and weighting.
Linkages allow the mind mapper to layer in nuances that might not be observable without repeating entries.
I consider these rules to be important, but not absolute.Â I have created many mind maps whose branches include links to websites or whole paragraphs of notes.Â I broke the â€śrulesâ€ť because breaking them provided more value to me than not breaking them.Â The only two hard and fast rules are:
The rules and guidelines for mind mapping exist to help the mind mapper get the most value from the map possible.Â The map should engage as many senses and learning styles as possible to get the job done.Â Tomorrow we tackle different uses of mind maps.
I've expressed my disillusionment with to-do lists before.
But let's try something simpler, a little experiment. What do you use to keep track of what you need to do? Hold it up, so I can see it. Humor me.
Seriously! No no no, hold it closer, near the screen here. Let me look at it. Let me get a good, long look at it.
Now imagine me slapping this thing out of your hand.
I just want to make a point, not break your fancy whatchamacallit. So pretend I slapped it into a soft fluffy pillow on the ground, not the hard concrete of the sidewalk. Though I probably should have.
Whatever that thing is, it's a crutch. You don't need it. It's hurting you more than it is helping. Get rid of it.
Instead, ask yourself this:What three things do you need to do today?
You should be able to instantly answer this simple question, each day, every day, for the rest of your life. Without any tools other than the brain you were born with.
If you don't have this skill, develop it. Practice, starting today. Right now.
What are you doing right now? Is it going to somehow result in one of those three things getting done today? Will this you get you to where you need to be by the end of the day?
I'm not asking you to admonish yourself or to make any changes to your routine. Just keep it simple, focus on the important things, and add a little layer of awareness.
So. Two items left. I'm doing pretty good today.[advertisement] Hiring developers? Post your open positions with Stack Overflow Careers and reach over 20MM awesome devs already on Stack Overflow. Create your satisfaction-guaranteed job listing today!
Ever come to a point where you feel you've learned enough to share your experiences in the hopes of helping others traveling the same road? That's what Martin Kleppmann has done in an lovingly written Six things I wish we had known about scaling, an article well worth your time.
It's not advice about scaling a Twitter, but of building a million user system, which is the sweet spot for a lot of projects. His conclusion rings true:Building scalable systems is not all sexy roflscale fun. It’s a lot of plumbing and yak shaving. A lot of hacking together tools that really ought to exist already, but all the open source solutions out there are too bad (and yours ends up bad too, but at least it solves your particular problem).
Here's a gloss on the six lessons (plus a bonus lesson):
Are you an iOS developer interested in adding a map to your application? The instructional experts at Code School set out to create a course introducing the Google Maps SDK for iOS to developers like you — and they delivered!
Exploring Google Maps for iOS is a free course covering everything from adding a simple map, to using geocoding and directions, to incorporating Street View in iOS. You'll end up with a working sample application and gain the knowledge you need to build your own amazing Google Maps-based apps. Learn from videos, sample code, and Xcode-based coding challenges.
Check out the introduction video below, and then head over to Code School to get started with their interactive course!
You can also read our official developer documentation and reference docs at https://developers.google.com/maps/documentation/ios/.Posted by Louis Gray, Googler
Wisdom begins when we learn the difference between "that makes no sense" and "I don't understand".
Mary Doria Russell
It is that difference that is needed to assess when a idea passes theÂ smell test.Â
These participants play off each other, react to emergent streams of melody, contribute their own special talent to the music and pretty much work in a a self directed manner over the course of the performance.
While I'm not a fan of analogies, this is a useful one for the purpose here. There are certainly domains where theÂ Jazz analogy describes what is going on in the trio in the picture to the left.
But what about other music? Music that is just as creative, just as moving, just as impactful to the listener. Beethoven's Ninth Symphony's Ode to Joy with the poem fromÂ Friedrich SchillerÂ 1785 work is an example.
Words that have moved nations and populations.Â Following Beethoven's Ninth was a movie we saw over the weekend that described this result.
In the Ninth, each performer has a score to follow, led by the conductor, but also by the concert master and the Â senior players in each section. The vocals are also led by a senior performer.
In the software business there are likely similar domains and projects. Ones that can be improvised and ones that require conductors, a concert master, and players who follow the score.
In both cases - and this is where the analogy falls apart - is the players are highly skilled, experienced in the art, having played the basic themes 1,000 of times over before improvising or following the score.Â
The jazz performance is not made up as it goes. OK, fusion is, but that crap makes my head hurt. Melodies,Â rules for cords are practiced for 10,000 hours (Gladwell), relationships between the players have magical connections not available to mere mortals. The Jazz Trio and theÂ Berlin Philharmonic are populated with highly skilled and experienced professionals. We've all heard our children play in the school band and know what that sounds like. All the platitudes in the world about agile axioms are of no worth without the necessary capabilities to actually get the work done properly.
Applying the notion that agile software development is likeÂ jazzÂ makes as much sense as sayingÂ I can sit in the 3rd chair of the trombone sectionÂ (my high school band position) and play my contribution to Beethoven's Ninth without a Curtis Institute degree in performance and 10 years experience (my aunt was a professional pianist in the late 1950's from Curtis).Â
It's not gonna happen - in both analogies - without the prerequisites of professional performance capabilities. Otherwise the result sounds like we're back in High School Music class with Mr. Meach (my teacher).
So how long will it take us to be capable performing to a level needed to not Â smell like we're high school kids in the marching band? I don't know let's make an estimate.Related articles Analogies, the Good, the Bad, and the Ugly The "Real" Root Cause of IT Project Failure
Mind mapping is a technique for mapping information using color, pictures, symbols and, most importantly, a branching structure emanating from a central concept. Mind maps are built using a fairly standard set of practices.Â I will walk through two of the basic patterns used to construct mind maps.
The basic process flow for all mind maps is:
The basic process can be leveraged with minor tweaking for many different types of mind maps. Here is an example of a topic driven mind map:
In many cases the person building the mind map will have a general understanding of the major subdivisions, therefore listing the subdivisions makes sense. Where you are less sure I would let the subdivisions emerge using the starburst or shotgun method of developing a mind map (I will cover this on Wednesday). Regardless of technique, do not be afraid to add, change or delete subdivisions as you learn more or a better structure suggests itself.
Brainstorming is a good process to jumpstart breaking subdivisions down. When using this process for mind mapping, I generally begin with a bit of research to prime the pump and focus, followed by brainstorming to drive out details and then more research to fill in the gaps.
Drawing a topic-driven mind is generally where new mind mappers begin. A topic-based approach provides structure to guide building a mind map. The one downside I have experienced with beginning with topic-driven mind maps is that the assumption of major subcategories can be constraining (similar to an anchor bias). Generating a mind map in a group session that includes diversity of thought is one way to avoid constraints and to leverage mind maps to help think out the linear box.
If any of these items interest you there's a full description of each sponsor below. Please click to read more...
Many of you will know Roman Pichler as the author of Agile Product Management with Scrum. For the last few years Roman has been working on various ideas to support envisioning and ideation. I’ve asked him to write a guest post here describing his Vision Board and how it connects to Scrum’s product backlog. I’m sure you’ll find his ideas very interesting.
Scrum is a great framework for building a product with the right features. It encourages the use of a vision shared by the product owner, the ScrumMaster, the development team, and the stakeholders, and it provides a product backlog that allows the team to move towards the vision by creating product increments.
Unfortunately, there is little guidance on how the backlog is derived from the vision. Once we have an idea for a new product or new features, how do we know which user stories we should include in the backlog? And how can we tell who should be at the sprit review meeting to help us understand if we are building the right product?
In the worst case, we could implement the wrong stories, get feedback from the wrong people, and build a product nobody wants and needs.Four Questions
I have found it very valuable to answer the following four questions before stocking the product backlog:
Without knowing who the users and customers are and why they would employ the product, it’s impossible to write meaningful user stories. Similarly, we don’t understand what should make the product special and stand out, it is difficult to make informed decisions about the product functionality, the user interaction, the UI design right, and even the key architecture and technology choices. And without being clear on the business goals and the product’s business model, it will be hard to justify the investment and attract a budget.Enter the Vision Board
The Vision Board is a simple yet effective tool that helps agile teams capture their vision and systematically answer the four questions above. The following picture shows the Vision Board, and I explain its sections below. You can download the tool for free at: romanpichler.com/tools/vision-board/
Vision Statement is a concise summary of your idea that describes your intention and motivation.
Target Group describes the market or segment you want to address. You should state who the users and its customers are likely to be.
Needs describes the product’s value proposition: the problems and pain points the product removes, and the benefits or gains it creates for the users and the customers. The section should make it clear why people will want to use and buy your product.
Product summarises the three to five features that make your product stand out. These are likely to correlate to its unique selling proposition, and they should address the needs identified.
Value explains why it’s worthwhile for your company to invest in the product and how the business goals can be achieved. Sample goals are increase revenue, enter a new market, reduce cost, develop the brand, or gain a technological advantage.
Let’s take a look at an example to make this more concrete.A Sample Vision Board
Say we want to create a new game for children to help them enjoy more about music and dancing and learn about the topics. Then corresponding Vision Board could look like this:
The board above captures the overarching vision. It states children aged 8-12 as the intended users of the game and their parents as the customers. It lists three reasons why the kids would want to play the game, the key features of the product, and the business goal and how the business model could work.
The good news is the Vision Board above helped me to think through the market the value proposition and the business model of the new app. The bad news is it contains lots of untested assumptions that would make it a gamble to use the board to derive the product backlog. What’s required instead is to systematically identify and validate its assumptions.Validation with the Vision Board
Validating the Vision Board starts with identifying the most crucial assumption, the assumption that must be tested now to avoid late failure – finding out too late that the problem is not worthwhile solving. Once you have identified the appropriate assumption, decide which method is best to address it and who should be in your test group.
Some of my favourite techniques for testing Vision Board assumptions are direct observation – watching target users and customers get a job done, for instance, observing how children play music games on the computer today – and problem interviews – talking to members of the target group about how they accomplish a job today, for instance, what’s good and bad about playing computer games, particularly those related to music and dancing.
Once you have run a test, collect the relevant data and analyse it. Then use the newly gained insights to change the board either radically or incrementally. An example of the latter is to adjust a need or to replace a key feature. But a radical change – called a “pivot” in Lean Startup – profoundly affects one of more sections of the Vision Board. The vision stays true but the path towards the vision changes. For instance, changing the product to an app that teaches children dancing by encouraging them to try out the moves themselves would be a pivot for the dance game.From Vision Board to the Product Backlog
Once you have validates the key risks and critical assumptions on the Vision Board, use it to create the initial product backlog and discover the right stories, interactions, and UI design, as the following picture illustrates.
With your initial backlog and the Scrum team in place, you are ready to start sprinting.Summary
Before writing user stories, coming up with user interface ideas or the user interaction, make sure you understand who the users and customers are, why they would use and buy your product. Find out what makes your product special, what your business goals are, and how you can meet them. As Joel A. Barker puts it: “Vision without action is merely a dream. Action without vision just passes the time. Vision with action can change the world.” You can learn more about working with the Vision Board and download the template for free at: romanpichler.com/tools/vision-board/
There is a continuing discussion in the agile community about deliveringÂ value in the order set by the customer. Along with this discussion is the use of the wordÂ DONE. A popular phrase is no requirement or piece of software can be consideredÂ DONEÂ until it is put to use.Â
This is a software developers point of view of course. But there is another view of software based products. It starts with theÂ Measures of Effectiveness for the resulting product. These Measures of Effectiveness are:
Operational measures of success that are closely related to the achievements of the mission or operational objectives evaluated in an operation environment, under specific conditions.
This measure ofÂ DONE is not directly related to code, testing, requirements or anything like that. It is related to howÂ Effective the software is in delivering the capabilities needed to fulfill the mission or business case.Â
The individual requirements and pieces of code that implement them can be - or should be - traceable to these capabilities. For each Measure of Effectiveness, we then need a Measure of Performance. These measures characterise:
The functional or physical attributes relating to the system's operation, measured or estimated under specific conditions.
These are also not direclty related to producing code, running tests, or other direct software activities.
All the software design, testing, integration, etc. supports the creation of theÂ ability to produce these Measures of Performance and Effectiveness. For the end user, all the development work is behind the scenes. What the customer actually bought was the ability to do something useful. To put a capability of the software system to work accomplishing a business need. Make money with this capability of course.
So What Does All This Mean?
It means that if you start at the bottom - with the software development processes - you're likley not going to see what the real picture is. This picture is that the customer paid for capabilities, measured in units of effectiveness and performance.
When we start with methods, paradigms, even cockamamie ones like not estimating the cost of the work effort needed to produce the capabilities, we loose the connection to why we are here. We are here to produce software that provides a capability. Likely more than one capability.
So when we hear words like -Â we can manage projects without knowing the costÂ orÂ we'll let the requirements emerge, orÂ the customer doesn't really know what they want, so we'll get started so they can decide along the way, ask how you are going to recognizeÂ DONE, before running out of time and money?Â
How Do We Discover the Needed Capabilities?
Once we've decided that capabilities are in fact the place to start, how are they gathered. Here's the top level set of activities.
Once we have these, we can start to elicit the technical and operational requirements that will fullfill these capabilities.
These requirements can be emergent, they can evolve, they can be elicited incrementally and iteratively. But what ever way toÂ appear they need to have a home. They need a reason for being here. They need to enable a capability to be available to the user.Â