When most people think about estimating, they are thinking about bottom-up estimating. When your car needs to be repaired, you bring it to a mechanic. If you need new brakes, you will get an estimate for the cost of the brakes and the amount of time that is required to install them. If you also need an oil change, then the cost of that is added to your estimate. Software developers tend to think the same way. They attempt to identify the tasks that must be performed. They estimate the time for each task and add up these estimates. Agile developers do this. The steps of agile estimating are explained in Traditional Agile Estimating.
Some organizations already have Software Development Life Cycles (SDLCs) that they have specified. These SDLCs give all of the tasks that must be performed to develop software. However, many of the steps have to be broken down into finer detail. For example, there may be a task called Code Modules. However, that is both difficult to estimate or control. It ends up being broken into Code Payment Screen, Code A/R Report and a host of others. Early in the life cycle, it is very difficult to specify all of these tasks and impossible to estimate them.
People involved in agile development usually think of estimating from the bottom-up. They will identify as many user stories as possible early in the life cycle. They will then use a technique like estimating poker to assign story points. In summary, estimating poker is a collaborative technique that involves the development team. User stories are considered one at a time. Each team member assigns a number of story points to the story. They discuss it until they reach consensus and then move on to the next user story.
Managers love the idea of bottom-up estimating. If all of the tasks necessary to develop an application are estimated, they can be placed in a work breakdown structure and a Gantt chart. This gives the illusion of control. The developers love the idea of bottom-up estimating. Stories and tasks must be identified as part of the development process. Therefore, the bottom-up estimate is not extra work just associated with estimating. This is consistent with agile principles and practices. Statisticians love the idea of bottom up estimating. Whether estimating by task or user story, each component gets its own estimate. The estimates will usually be incorrect, but the errors will tend to cancel each other out. In theory, it is a winning approach. In practice, you just cannot do bottom-up estimating early in the life cycle. Project sponsors, end users and business analysts are developing any application artifacts like a feasibility study. Sponsors and users do not know what logical data models are. Business analysts know what they are, but probably have no idea how long it will take to develop one before the scope of the project is better established. For many applications, the development environment has not yet been decided on. Data warehouse applications may be developed using special software packages with entirely different development tasks than an organization typically specifies in its SDLC. In most cases, bottom-up estimating is impossible to do correctly early in the life cycle.
Top-down estimating begins with establishing the size of the application to be developed. Knowing this, algorithmic models were used to predict how much effort and how much calendar time would be required to develop the application. This approach was developed when the waterfall approach to software development was popular. Therefore, these models typically predicted how much time would be spent in the analysis, design and coding phases of the application development. Some approaches would predict the amount of time for various activities, like project management. In the beginning, that size was expressed in lines of code. There were two problems with this. First, you only know the number of lines of code after you have developed the application. Then you do not need the estimate. However, many organizations developed heuristics to help them predict lines of code. These rules of thumb were tied to the experience of the organization. For example, at one time NASA would predict the number of lines of code in satellite support software based on the weight of the satellite itself. The second problem can be summarized by Capers Jones’s statement the using lines of code should be considered professional malpractice. There are many problems with it. In one of his books, Capers shows that it often misrepresents the value of software. For example, is 2,000,000 lines of assembly language more valuable that 20,000 lines of COBOL?. Should it take 100 times longer to write? Even more to the point, with so many development environments being build around screen painters and other tools that do not actually have lines of code, the antiquated measure has become unusable. Function points, use case points and a host of lesser known measures have taken the place of lines of code. Barry Boehm (no relation) developed several estimating models that he called the Constructive Cost Model (COCOMO) in 1981. One of models was Basic COCOMO. It transformed the number of lines of code into the person-months of effort and the calendar months of schedule that would be required for application development. Practitioners at he time found ways to drive COCOMO from function points as opposed to lines of code.
Basic COCOMO was not as accurate as people wanted. Therefore, Boehm introduced Intermediate COCOMO at the same time. He actually introduced product level and component level versions of Intermediate COCOMO, but the difference is not important at this point. What is important is that Intermediate COCOMO utilized cost drivers. Cost drivers impacted the estimates. They were necessary and made sense. Imagine there are two applications that are 100,000 source lines of code. Will they take the same amount of time to develop? Probably not. There will be two types of differences between the two application projects. The first type are product differences. One application might be a computer game and the other an embedded system in a piece of medical equipment. The second application will have a higher required reliability. This will impact its development time. There are other product related cost drivers. The complexity of the products may also be different and impact the development time. The other class of cost drivers are associated with the development process. How experienced is the team with this type of application? How experienced is the team with the development language/environment being used? These cost drivers also impact development effort and schedule. In fact, cost drivers can change development effort by an order of magnitude.
COCOMO was not the only costing model around. At about this time, Larry Putnam introduced Software Lifecycle Management (SLIM). The Walston-Felix IBM-FSD Model and the Price-S model were two other top-down models that were introduced at about the same time. Which one was best? Nobody knows! There were several bake-offs but none actually answered that question. It turns out it was impossible to answer. Which car is best? In 1969, I saw a move called Grand Prix. Pete Aron is a race car driver who is just about unemployable. He was reckless. A Japanese car company hires him. He wins the race. Why? If you are reading this today, and obviously you are, then you might think it was because the Japanese are capable to making a fine automobile. In 1969, this would never of occurred to you. The Japanese had introduced motorcycle to America and they were a failure. Japanese cars would be the same. Pete Aron won the race because it is the driver, not the car that wins the race. He was driven to win and afraid to lose. That is all there was to it. Automotive enthusiasts might debate the. However, when it comes to estimating there is no debate. It is the estimator, not the model, that produces a useful estimate!
Practitioners started to use function points to drive the top-down models. Capers Jones had produced some tables that showed how many lines of code were required to implement a function point. Thus, function point could drive models like COCOMO. Some practitioners used unadjusted function points. There were complications when the Value Adjustment Factor (VAF) was used. Which General System Characteristics (GSCs) resulted in more lines of code? They were not adequate to use in place of cost drivers. A minimum VAF would make the adjusted function point size 65% of its unadjusted size; maximum would be 135%. The size difference is only a factor of 2. Cost drivers could usually impact the estimates to a much greater extent. Now, the International Function Point Users Group (IFPUG) has introduced the Software Non-functional Assessment Practices (SNAP). This is a counting approach that might replace the product cost drivers, but not the process ones.
These top-down techniques can often be performed by someone who is not familiar with all of the nuances of system development. The individuals must be familiar with the model being used, such as COCOMO. In addition, they must be trained in the sizing measure being used, such as function point analysis. This means that there is usually a small group of estimators in most organizations. In an organization using agile development, this might be a function that the product managers take on. This way, they can report back to the sponsors and other users what they expect in terms of schedule for an application development. Many organizations rely on consultants to perform these estimates. An independent estimator is often a good choice. This estimator is not overstating an estimate in order to negotiate for more resources, nor understating the estimate in order to pressure the development team to deliver faster.
Estimators look for techniques that are orthogonal to one another. This means that they are statistically independent. Top-down and bottom-up estimating approaches can be orthogonal. The bottom-up method is usually performed during the development just by virtue of identifying tasks and assigning people to them. If a top-down estimate has been developed, then it can be compared to what is being indicated by the bottom-up estimate at any time.
In the perfect world of agile systems development, all of the activity goes directly into developing application code. This is a drawback of top-down estimating. The effort that goes into it does not directly implement the application. If that effort is performed by a non-developer, then it becomes more of a business decision of whether the time and effort spent in developing the effort is helping the project sponsor to make better business decisions. Another area of concern is the distraction that this may be for the development and user communities. If the developers must answer questions in order to size the application, then this detracts from development effort. If a user must answer questions, then that user may be distressed if and when a developer asks the same questions again. The value of the estimate must exceed these costs or it should not be done.
The most modern of the cost models do not fit neatly into the bottom-up or top-down category. COCOMO II has replaced COCOMO the model of choice among COCOMO fans. SPQR, Checkpoint and Knowledge plan were released by Software Productivity Research (SPR), then under the direction of Capers Jones. Dan Galorath’s SEER-SEM is one of the more recent, commercially successful estimating models. The pros and cons of these approaches are basically the same as top-down models.
This is part of a three-part series on keeping remote teams cohesive. We recommend that you begin...
The post Keeping Remote Teams Cohesive, Part 3: (Over-) Communication is Key appeared first on Blog | LeanKit.
We've found a piece of legacy functionality from Targetprocess 2 that's been quite useless for several years — since the days when the multi-project concept was first released: Tags Bundles.
Tags Bundles are similar to a group of Tags, and were used in conjunction with features that are either outdated or have been removed. So, we wanted to let you know that we will be saying goodbye to Bundles in a few releases.Recent Items and Browsing History
Every v.3 user has faced the challenge of quickly finding some entity which they recently viewed or modified. To fix this, we've added a special 'My Recent' tab to the views list so you can find quickly the entities that you've opened or edited lately. The tab shows the 15 most recently modified items which you own, and the 15 most recently modified items which you are assigned to. In the 'Browsed' tab, you can find a list of entities which you've opened recently.
- You can customize Project cards with a new unit ('Last State Change Date') and filter Projects by the date of their last state change
- Fixed Quick Add exception in case a 'Targetprocess Entity Type' required custom field is in the form
- Fixed timesheet page errors which appeared if a Project's abbreviation had special symbols
I have a new article up on projectmanagement.com, Continuous Agile Program Planning: Think Big, Plan Small. It’s about how to use rolling wave planning especially for an agile program.
If you are a Product Owner or you are responsible for planning what when, and want to learn how to do this, join my PPO Workshop, starting next week.
I don’t know if you retrospect on a regular basis. I do. (I know, you are so surprised!)
Andy Kaufman asked me to share my biggest learning for his podcast. Take a listen to The Most Important Lesson You Learned Last Year. I’m pleased and proud to be in such good company. Thanks, Andy!
Grace Hopper and Margaret Hamilton were recently named among 21 recipients of the Presidential Medal of Freedom in honor of their contributions to the advancement of computer technology. Their names are well known among software professionals, even if not as familiar to the general public.
Hopper was fascinated by gadgets, and when she encountered the Mark I computer in the Navy she was hooked. She became only the third person to try and program the machine, and ultimately was awarded the Naval Ordnance Development Award for her work.
Later she developed the first compiler. Called A-0, or Arithmetic Language version zero, it comprised a set of pre-built subroutines that could take immediate arguments. It functioned as a loader or linker, and did not have text parsing functionality; but it was far more than had been done previously.
Her interest in making computers usable by humans led her to drive a series of improvements in compiler technology, from A-0, A-1, A-2 (ARITH-MATIC) to AT-3 (MATH-MATIC) to B-0 (FLOW-MATIC) to COBOL (Common Business Oriented Language). At its height in the late 20th century, COBOL is thought to have represented about 97% of all production business software worldwide. Not a bad legacy.
Hopper was a high-energy person well known for perseverance. One of her favorite catch-phrases was, “It’s better to ask for forgiveness than permission.” She was determined to figure out a way to get things done.
Years later, Margaret Hamilton would demonstrate the same personal traits and would drive further advancement in the field of software. Contrary to many of the popular accounts that name her as the “head” or “lead” or even the sole author of the software used on the Apollo flights, Hamilton joined the NASA team as the junior-most programmer.
She came to the job with a background in mathematics rather than engineering, and with no more idea what a “programmer” does for a living than anyone else on the team. In those days, there was no such job description. As Hamilton put it in an interview years later, “Because software was a mystery, a black box, upper management gave us total freedom and trust. We had to find a way and we did.”
It was hammered into everyone that this had to be a zero-defect system. If an error occurred a quarter million miles from Earth, the astronauts would die. So, Hamilton inquired as to how the team was ensuring defect-free software. The answer: Augekugel.
She pressed the question and learned this meant “eye-balling.” There was one guy who was pretty adept at spotting potential integration errors by examining the source code visually. Hamilton thought this was a bit risky. She sat with him and learned his method. Eventually she saw that it was a pattern recognition process, and she perceived it could be done programmatically. She invented Higher Order Software; software that operated on other software rather than the domain problem. Today we call it static code analysis.
In the Lunar descent phase of the Apollo 11 mission, another of Hamilton’s innovations came into play. Although they were top-tier test pilots and had completed a massive amount of training, Neil Armstrong and Buzz Aldrin were doing something no one had done before, and it was hardly routine. There are detailed reports of what happened, but in a nutshell the astronauts basically turned everything on and loaded every program, just in case.
Turning everything on was a mistake, as there was a known issue with RF interference between the guidance computer and the rendezvous radar, which Aldrin switched on even though it was not needed in the descent phase. Loading the ascent program was a mistake, as the limited memory in the guidance computer didn’t allow for all the programs to be loaded at once, and that program was not needed in the descent phase.
Between sporadic hardware errors and the scary 1201 and 1202 messages on the little numeric console, the astronauts decided to land manually. Those error codes pertained to another innovation of Hamilton’s – the system could dump programs it didn’t need in order to free up scarce memory resources for the programs it did need. When the astronauts loaded too many programs, the system dutifully dumped the unnecessary ones, based on the mission phase they were in. Despite the scary-looking error codes, there was nothing wrong with the computer or the software.
By that time, Hamilton’s value to the team had been well proven time and again. But initially, she was the junior member of the team. They gave the junior team member the least important program to write. They called it the Forget It program. It would be executed in case of some catastrophic failure. They figured there would be no catastrophic failures. Fast forward to Apollo 13, and Hamilton is in the forefront of the recovery effort.
After Apollo, Hamilton and the person who actually was the team lead, Dan Lickly, formed a company they called Higher Order Software. They were ahead of their time, it seems. Companies weren’t interested in static code analysis…or else the mathematician/programmer and the engineer/professor just weren’t good at sales. Today, it’s almost unthinkable to run a professional software delivery organization without static code analysis. Not a bad legacy.…there’s a way
When I read that Hopper and Hamilton had been honored by the President, it put me in mind of the attitude we encounter so often in large companies today. People are just one or two steps away from automating something, and they stop short. They continue to repeat the same tasks manually, dozens or hundreds of times per year.
A development team may have a well-vetted and clearly-documented procedure to run tests, integrate their code, and deploy. But they never convert their documentation into an executable script. It would save them so much effort and time!
People are pretty skilled at finding excuses not to do things. At one company, teams were hesitant to set up a continuous integration server because their architecture team was still mulling over the choice of product. I still don’t understand why the team couldn’t set up their own CI server in the meantime. It would have made their lives easier, and they would have worked out any kinks in the general CI process, making the transition to the “official” product that much smoother. Oh, well.
An infrastructure team may have a well-vetted and clearly-documented procedure to provision virtual servers of various kinds. But they never convert their documentation into executable scripts. It would save them so much effort and time!
At one company, the infrastructure team maintained a few hundred servers, mostly VMs, and mostly standard build-outs. One of the guys told me they didn’t script any of the builds because some of the systems were one-off configurations that supported legacy applications with built-in dependencies on various obsolete things. Okay, that’s understandable, but what about the 80-90% of configurations that were standard? Why not go ahead and script those? An individual engineer could at least script his/her own repeated configuration tasks, even without telling anyone about it. Wouldn’t that make for an easier work day? Oh, well.
Maybe I’m the one who’s wrong, here. Maybe I’m just too lazy to repeat the same manual tasks over and over again every day. Maybe I should be more diligent. I’ll work on that one of these days. Promise. Maybe.
If I’m not wrong, then I’m not sure what’s missing, unless it’s the preference to ask for forgiveness rather than permission, or the determination to find a way. As the recent Presidential awards suggest, there are role models available for that sort of thing.
A Strengthening Boldness
With the arrival of 2017 it’s hard to believe how fast 2016 went by. It’s even harder to believe it’s been 6 years since the first resolutions post back in December of 2011. You can take a look back at all of them with these links:
As I sat down to write the resolutions for 2017, I decided to expand the scope of this annual activity beyond Scrum Masters to include anyone looking to be a catalyst for positive change in their organizations. The more I’ve been doing what I do, the more I realize the importance of each individual being an active ingredient in the creation of an environment of connected agility.
So regardless of your role – a team member, Scrum Master, product owner, senior leader, manager, coach, or anyone in between – these resolutions are crafted with you mind. The strong and the brave willing to break out of the status quo and be an active participant is shaping a workplace where bonds strengthen and creativity flows.
If there is a theme to the resolutions this year I guess it would be “A Strengthening Boldness.” Throughout the month of January, I will be blogging and podcasting about how change is introduced into the workplace. To embed change into how we work, it will require bold people doing bold things. Watch the video in a blog post from 2012 to see what I mean. Hopefully, these resolutions will provide a spark of boldness for you (and for me) as we venture into a new year.
But before we jump into the resolutions, I would like to express a quick but sincere thank you to the readers of The Illustrated Agile Blog and to the listeners of The Illustrated Agile Podcast throughout the year. It’s been great interacting with you in 2016 and I can’t wait to experience the adventures we can stir up in 2017.
So here they are…the 2017 Resolutions for Agile Catalysts Everywhere. If you have any of your own to add to the list please share them with all of us in the comments below.
Strengthen others. Resolve to make every interaction with others meaningful and memorable. When people leave a conversation with you they should feel bigger, encouraged, stronger, happier and more alive. This investment in the well-being of others will not only reinforce the team bonds, it will begin to release confidence throughout your workplace. While this is important for everyone, if you have people reporting to you put this one at the top of your list. If you find you can’t genuinely be a force of positivity with someone then you probably need to learn more about them. Hence…
Really learn about your teammates. Resolve to connect with someone and discover as much as you can about them. Maybe pick someone who you may not know very well or someone who, on the surface at least, might be quite different than you. Names of people are popping into your mind as you read this. Commit to reaching out to them as soon as possible.
If you’re not sure where to start, grab them for a quick coffee or a walk and have starter questions ready. A few could be:
- How are things outside of work?
- Are you feeling the strength of being a part of our community?
- Do you feel your voice is being heard?
- Are you growing in your role?
- What is the biggest challenge you’re facing right now?
Find a mentor. If you don’t have someone who is inspiring you, challenging you, encouraging you and pushing you, resolve to find someone who can fill this role for you…today. I’ve written about the importance of finding a mentor in the past. This act of surrounding yourself with a person willing to unselfishly give of their time for the purpose of your own growth will provide dividends for the rest of your life. It has for mine.
Be a mentor. The only way this mentor thing works is if you subsequently become a mentor to somebody else. Resolve to take someone under your wings and become fully responsible for their growth and well-being this year. While this may seem daunting, just a few interactions and periods of sharing and conversing is all it takes to get started. If you are not sure who you can be a mentor to, continue the “learn about your teammates” resolution until you find someone. Your experiences could be just what someone else needs to inspire them to greater things.
Default to action. This is the biggest thing I’m working on for 2017. I’ve recently found myself in the habit of telling people, “Let me know if you need any help.” My resolution this year is to stop asking if people need help and to JUST START HELPING. Many people will never “let you know” if they need help even when they need it the most. While this will require a little more sacrifice of time, rolling up our sleeves and doing work together is how communities bond and connections strengthen.
Think simply. The book “Essentialism” mentioned the phrase “less but better.” I’m thinking this will be the phrase I will be frequently saying to myself this year. Resolve to take a hard look at how people in your organization, department, or teams really get things done and decide to do fewer things better. This will require hard decisions to be made about what is really important. For Scrum Masters and Coaches, start every conversation about how we should work (or how we should be Agile) with the question, “What is the simplest thing we can do?”
Think radically. With the pace of change in the world accelerating, by the time you’ve become “Agile” it will not be enough to keep up with future challenges. So in 2017, resolve to start thinking about fresh ideas. Better yet, start experimenting with seemingly “radical” ideas. Add creative things to otherwise mundane activities. Add mundane things to otherwise creative activities. Change things up. Ask daring questions to everyday problems and provide daring answers when a typical response would be expected. Be a shock the system.
Looking forward to an amazing 2017 with all of you!Becoming a Catalyst - Scrum Master Edition
The post Resolutions for Agile Catalysts Everywhere (2017 Edition) appeared first on Illustrated Agile.
“Whatever you can do, or dream you can, begin it. Boldness has genius, power and magic in it.” — Johann Wolfgang Von Goethe
It’s time to dig down, dig in, and dig deep to create a great year for yourself and others.
I’m a fan of hacks for work and life.
I find that hacking away at challenges is a great way to make progress and to eventually overcome them.
Hacking is really an a approach and a mindset where you try new things, experiment and explore while staying open-minded and learning as you go.
You never really know what’s going to work, until you’ve actually made it work.
Nothing beats personal experimentation when it comes to creating better results in your life.
Anyway, in the spirit of kicking off the new year right, I created a comprehensive collection of the ultimate hacks for a happy new year:
This is no ordinary set of hacks. It’s deep. There are hacks for mind, body, emotions, career, finance, relationships, and fun.
There are hacks you can use everyday to change how you think, feel, and act.
There are hacks to help you change habits.
There are hacks to help you relight your fire and get back in the game, if you’ve been in a slump or waiting on the sidelines.
Jump back in the game, master your work and life, and have some fun in the process.
Here is a quick list of the hacks from 101 Hacks for a Happy New Year:
1. Get the power of a New Year’s Resolution on your side
2. Limit yourself to one big resolution at a time
3. Get specific with your goals
4. Dream bigger to realize your potential
5. If you want change, you must change
6. Guide your path with vision, values, and goals
7. Change a habit with Habit Stacking
8. Create mini-feedback loops
9. Bounce back from a setback
10. Avoid “All or Nothing” thinking
11. Choose progress over perfection
12. Reward yourself more often
13. Gamify it
14. Adopt a Tiny Habit
15. Just Start
16. Adopt a growth mindset
17. Create if-then plans to stick with your goals
18. Start with Great Expectations
19. Adopt 7 beliefs for personal excellence
20. Master the art of goal planning
21. Prime your mind for greatness
22. Use dreams, goals, and habits to pull you forward
23. Use the Exponential Results Formula to make a big change
24. Adopt the 7 Habits of Highly Motivated People
25. Use Trigger Moments to activate your higher self
26. Use Door Frame Triggers to inspire a better version of you
27. Find your purpose
28. Figure out what you really want
29. Use 3 Wins to Rule Your Year
30. Commit to your best year ever
31. Find your Signature Strengths
32. Practice a “lighter feeling”
33. Let go of regrets
34. 15-Minutes of Fulfillment
35. Create your ideal day the Tony Robbins Way
36. Master your emotions for power, passion, and strength
37. Start your year in February
38. Build your personal effectiveness toolbox
39. Write your story for the future
40. Get out of a slump
41. Give your best, where you have your best to give
42. Ask more empowering questions
43. Surround yourself with better people
44. Find better mentors
45. Do the opposite
46. Try a 30 Day Sprint
47. Grow 10 Years Younger
48. Don’t get sick this year
49. Know Thyself
50. Decide Who You Are
51. Decide Who You Want To Be
52. Cultivate an Attitude of Gratitude
53. Try 20-Minute Sprints
54. Create a vision board for your year
55. Adopt some meaningful mantras and affirmations
56. Practice your mindfulness
57. 15-Minutes of Happiness
58. Breathe better
59. Become your own gym
60. Master your wealth
61. Learn how to read faster
62. Let go of negative feelings
63. Live a meaningful life
64. Establish a routine for eating, sleeping, and exercising
65. Improve your likeability
66. Win friends and influence people
67. Improve your charisma through power, presence, and warmth
68. Fill your mind with a few good good thoughts
69. Ask for help more effectively
70. Attract everything you’ve ever wanted
71. Catch the next train
72. Unleash You 2.0
73. Learn anything in 20 hours
74. Use stress to be your best
75. Take worry breaks
76. Use the Rule of Three to rule your day
77. Have better days
78. Read 5 powerful personal development books
79. Practice the 10 Skills of Personal Leadership
80. Develop your Emotional Intelligence
81. Cap your day with four powerful questions
82. Build mental toughness like a Navy Seal
83. Feel In Control
84. Transform your job
85. Use work as your ultimate form of self-expression
86. Be the one who gives their all
87. Live without the fear of death in your heart
88. Find your personal high-performance pattern
89. Create unshakeable confidence
90. Lead a charged life
91. Use feedback to be your best
92. Make better decisions
93. Learn how to deal with difficult people
94. Defeat decision fatigue
95. Make the most of luck
96. Develop your spiritual intelligence
97. Conquer your fears
98. Deal with tough criticism
99. Embrace the effort
100. Finding truth from the B.S.
101. Visualize more effectively
For the details of each hack, check out 101 Hacks for a Happy New Year.
I will likely tune and prune the hacks over time, and improve the titles and the descriptions.
Meanwhile, I’m not letting perfectionism get in the way of progress.
Go forth and hack a happy new year and share 101 Hacks for a Happy New Year with a friend.
Previously we modified our setup to use a role from ansible galaxy to install and configure redis. One key thing lacking here is that one…
Here are the tweets you likely missed last month!
— SonarQube (@SonarQube) December 7, 2016
— SonarQube (@SonarQube) December 22, 2016
— SonarQube (@SonarQube) December 15, 2016
— SonarQube (@SonarQube) December 16, 2016
— SonarQube (@SonarQube) December 16, 2016
— SonarQube (@SonarQube) December 14, 2016
— SonarQube (@SonarQube) December 15, 2016
— SonarLint (@SonarLint) December 14, 2016
I have another update for the planned Docker Recipes for Node.js ebook – this time focused around the pricing and pre-sale dates.
The Pre-sale Dates and Prices
These are the details that you need to know, to take advantage of the significant discount that I’ll offer during the pre-sale, and be able to participate in the feedback cycles of the book.
- Pre-Sale Dates: January 16th – 31st
- Pre-Sale Price: $9
On January 16th, 2017, the pre-sale will start and run through the end of January. It will be open to the public and will be announced here, through my mailing list, on twitter, etc.
During the pre-sale, you’ll be able to pick up the ebook for only $9. This will be a significant discount compared to the final price, while also giving you opportunity to be involved in the feedback cycles and direction of the book.
But there’s more to the pre-sale than just the dates and price.A Pre-Sale Goal
I’m setting a goal with these pre-sales, to help me determine whether or not the book is really worth writing (though I suspect it is)
- Pre-Sale Goal: 100 sales @ $9 each
If I don’t hit 100 sales in the pre-sale timeframe, the book will likely be delayed or may be cancelled entirely (refunds would be issued, if that happens).
Having a group of people dedicated to providing feedback is important to this book’s content. But I understand that not everyone will be able to provide feedback in a timely manner, for all updates to the book.
With 100 copies sold in the pre-sale, however, I should have enough people who can provide the needed feedback, even if a large percentage are out of pocket in the same time period.
The revenue from these sales will also give me more options for editing, review, and possibly work on additional materials. I don’t yet have any specific plans for these aspects, but I want to leave open the possibility that more pre-sales revenue will create a better end result.Book & Bundles For Pre-Sale Purchases
The pre-sale will likely only include 1 complete recipe at launch (as I mentioned in the last post), but the $9 price will get you much more than just the early release and final ebook.
As I’ve said already, you’ll have a chance to be involved in the feedback cycles and direction of the book. This will likely happen through a combination of email and access to the WatchMeCode community slack.
Pre-sale purchases will also be given updates to the book as they are released, and will get other related content when the book is complete!
The current plan is to have 3 tiers of content bundles for sale, with these as the final prices (subject to change).
- ebook only: $19
- ebook plus “more info” screencasts: $79
- ebook, “more info” screencasts, both WatchMeCode Docker guides: $199
Many of the recipes in this book will reference additional information found in WatchMeCode screencasts. Subjects such as using the Node.js built-in debugger are very relevant to the book, but not strictly something that should be covered in the book. The second tier package will include these “more info” and other related screencasts and materials.
Additionally, WatchMeCode already has Guides for Learning Docker and Node.js with Docker. The top tier package will include both of these guides, plus everything from the first two tiers. There may be additional materials included in this top-tier, but that is yet to be determined.
There’s an important note in these packages, for pre-sale purchases, as well.
All pre-sale purchases, at the $9, will be given the complete 2nd tier package!
That’s a $79 package for $9, as a giant thank-you for your feedback and assistance with the book.
You’ll also get a significant discount on the top-tier package (probably near 50% off).The Pre-Sale Starts January 16th
As I said above, the pre-sale starts on January 16th and runs through the 31st.
Once this pre-sale is over, sales will stop so work can begin on the content and collaboration with the pre-lease buyers.
If you’re interested, at all, in getting this book at a the cheapest possible price and ensuring it is released as planned, join the mailing list (below) and be ready for the launch on January 16th.Tweet
The post Docker Recipes for Node.js: Pre-sale Dates & Details appeared first on DerickBailey.com.
The second is psychological safety that is core to enterprise effectiveness. According to Google research, high performing teams always display psychological safety. This phenomenon has two aspects. The first is where there is a shared belief that the team is safe to take interpersonal risks and be vulnerable in front of each other. The second is how this type of safety along with increased accountability leads to increased employee productivity and ergo high-performing teams. Psychological safety helps establish Agile in that it promotes a safe space for employees to share their ideas, discuss options, take methodical risks, and become productive. An Agile mindset promotes self-organizing teams around the work, taking ownership and accountability, and creating an environment for learning what is customer value through the discovery mindset, divergent thinking, and feedback loops. Agile with psychological safety can be a powerful pairing toward high-performing teams.
However, accountability without psychological safety, leads to great anxiety. This is why there is a need to move away from a negative mindset when results aren’t positive or new ideas are seen as different. If this occurs, employees are less willing to share ideas and take risks. Instead consider ways to build psychological safety paired with team ownership and accountability of the work. This can lead to high performing teams.
Everyone has a role to play in establishing a psychologically safe environment. Agile Coaches and ScrumMasters can help you evolve to an enterprise where psychological safety and accountability are paired. Leadership has a strong role to play to provide awareness of the importance of a safe environment, provide education on this topic, and build positive patterns in the way they respond to results of risk taking by teams. Team members must adopt an open, divergent, and positive mindset that is focused on accepting differences and coaching each other for better business outcomes. Employees at all levels must be aware of the attitudes and mindset they bring.
Jared was a beloved husband, father, brother and son who has touched many lives. In his professional career, Jared was a consultant, developer, tester, and manager, including Director of Development at several companies. He was the author of two books, Ship It! and Career 2.0, and was the 2nd public signatory of the Agile Manifesto. Jared was Screencast Editor for the Pragmatic Bookshelf, and co-founded The GROWS™ Method. He started AgileRTP in 2007 and is well known as a coach and consultant through his company, Agile Artisans.
Jared was called home on December 7th, 2016 to be with our Lord. He was surrounded by his family and passed peacefully. In accordance with his wishes, his organs have been donated so that others may benefit from this tragic loss. As he did so much in life, Jared kept giving of himself even in death.
We're collecting your stories at https://www.remembr.com/jared.richardson on how Jared has touched