Skip to content

Companies

A Personal Manifesto

NetObjectives - Sun, 05/28/2017 - 12:24
Background and the Agile Manifesto. I have been asked several times to help in the rewrite of an Agile Manifesto.  After having been involved in Snowbird 10 (the reunion of some of the original Agile Manifesto authors along with some others from the Lean/Kanban community) I realized there is no “Agile” community. Rather we have many sub-communities that are so diverse it is hard to think of them...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

Private and pinned comments for Requests

TargetProcess - Edge of Chaos Blog - Fri, 05/26/2017 - 22:55

In the upcoming version of Targetprocess (v.3.11.4), there will be two changes related to comments: the long awaited “private” comments, and the ability to pin comments. These will only be available for Requests, and are mostly designed to improve the Service Desk experience.

Private comments

We fully support openness, transparency and all that, but when dealing with requests from external users, you often have to exchange some internal comments with developers or fellow support folks. Previously, this was tricky because all comments were available to customers in Service Desk. Now you can mark the comment as private so that it stays hidden for requesters.

Don’t go too far though; other people with a Targetprocess license will still be able to see the comment in both Targetprocess and Service Desk, so please don’t upload photos from your last party, or something like that.

private-comment

Pinned comments

If you're doing Idea Management and have some popular ideas, you might get dozens of comments from both customers and your own team. No one likes scrolling through through text to see whether or when an idea is going to be implemented, so what will people often do? That's right, post another question. Now you can “pin” a comment to a Request to give it its own "Last Official Comment" section in Service Desk. This way, customers will see current status at a glance.

last_official_comment

Categories: Companies

GitKraken v2.6

About SCRUM - Hamid Shojaee Axosoft - Tue, 05/23/2017 - 21:26

“You know my methods, Watson,” said Sherlock. “There was not one finder command which I did not apply to the inquiry.”

Okay, so maaaaaybe that’s not quite what Sir Arthur Conan Doyle wrote, but Sherlock’s detective skills surely inspired the new and improved Fuzzy Finder in GitKraken version 2.6.

With this release, we’re trying something a little bit different. We’ve put together a video—and this article—to cover what’s new. Watch the video or keep reading, the choice is yours! Let us know which you prefer.

Fuzzy Finder

To bring up the improved Fuzzy Finder, use the keyboard shortcut Cmd+P for Mac or Ctrl+P for Windows and Linux.

GitKraken Fuzzy Finder

After you’re done looking into the curious incident of the dog in the night-time, you can use the Fuzzy Finder to perform any of the following actions:

Repo:
  • Init
  • Open
  • Open in file manager
  • Clone
Settings:
  • General
  • Git Config
  • Authentication
  • GitFlow
  • UI Preferences
View:
  • Toggle Left Panel
  • Increase Zoom
  • Decrease Zoom
  • Reset Zoom
  • Keyboard Shortcuts
History:
  • History + filename

The Fuzzy Finder has replaced the Command Palette; however, the old keyboard shortcuts Cmd+Shift+P for Mac and Ctrl+Shift+P for Windows and Linux, will still bring up the Fuzzy Finder.

gitkraken fuzzy finder keyboard shortcut

The actions listed below were previously performed through the Command Palette, but can now be performed using the Fuzzy Finder:

Core:
  • Undo
  • Redo
File:
  • Stage all changes
  • Unstage all changes
  • Discard all changes
Stash:
  • Create
  • Pop
  • Apply
Branch:
  • Create
  • Fetch
Checkout:
  • Checkout + branch name

Additionally, if you click the search box in the upper right corner—or use the keyboard short Cmd+F for Mac / Ctrl+F for Windows and Linux—it will search through commits by default.

Fuzzy Finder Shortcut

#GitKrakenTip: Use the Cmd+backspace / Ctrl+backspace shortcut to quickly clear out any searches or filters.

Other Updates

GitKraken will now politely inform you when you have an external rebase in progress. GitKraken will show this message and temporarily lock parts of the application until the external rebase has finished. You can still resolve conflicts from inside GitKraken at each step of the external rebase.

gitkraken external rebase message

Lastly, we updated the macOS title bar color for both dark and light themes.

gitkraken macOS title bar

As Sherlock once sarcastically put it, “The world is full of obvious things which nobody by any chance ever observes.” We hope our Fuzzy Finder helps put things in plain sight so that you need not have Holmes’ mind to perform actions that are quite elementary. To see what else is new and improved in GitKraken v2.6, continue your investigation over in our release notes.

Categories: Companies

Targetprocess v.3.11.3: User Stories will now follow their parent Feature

TargetProcess - Edge of Chaos Blog - Thu, 05/18/2017 - 08:01
User stories will now follow their parent Feature

Previously, if you moved a Feature to another Project, its User Stories did not follow the Feature to the new Project. This was fairly counter-intuitive. Starting with this release, if you move a Feature to a different Project, all of its User Stories will follow (as long as they were originally in the same Project as their parent Feature).

If you move a Feature to a Project with a different process, you will get a warning that this change might cause you to lose some custom fields.

screen-shot-2017-05-17-at-5-48-21-pm

Private Impediments have been removed

As described in this blogpost, we're removing this barely-used feature to improve performance and reduce complexity. Feel free to message our support team if you have any questions.

Fixed Bugs
  • Corrected the @user mention format for email notifications
  • Fixed the creation of a Test Plan with multiple Test Cases via REST API POST
  • The order of mandatory custom fields in Quick Add forms will now correspond to their order in entity views
  • Fixed a case where it was not possible unlink a Bug from a Test Case Run if its Test Plan Run is the child of another Test Plan Run
  • Improved the performance of Relations lookup
  • Fixed an incorrect term: When completing Team Iterations, the system would incorrectly describe them as Iterations.
Categories: Companies

GitKraken Tips V

About SCRUM - Hamid Shojaee Axosoft - Wed, 05/17/2017 - 20:03

Here is a roundup of our most recent 11 tips to help you become a bit more productive when you’re working. If this series is new to you, check out our previous tip roundups.

GitKraken Tips
  1.  Instantly open your current repo in a terminal window with alt/option + t, or from the File menu.
  2.  Push changes and start a pull request with one action. If you don’t have an upstream set, you’ll be prompted to set one first.
  3. Remote avatars in the graph help you see who is working on a branch. Get more info by hovering over those and other icons.

  4. The “Viewing” count displays how many branches/tags are visible in the graph. Quickly show all hidden items with “Show All”.
  5. Store HTTP & Proxy credentials to save time when pushing to remotes. They can be cleared in Preferences > Authentication
  6.  Create project groups in the new repo management view to keep your repositories organized.
  7. Open the Command Palette (cmd/ctrl + shift + p) or Fuzzy Finder (cmd/ctrl + p) and arrow down to see a list of shortcuts.

  8. You can drag-and-drop ref labels in the graph to merge, rebase, reset, etc. Multiple refs on one commit will expand on hover. 
  9. Pro users can create and switch between multiple profiles, each with unique settings and hosting service account integrations. 
  10. GitKraken’s easy-to-use conflict tool is even more powerful with Pro, giving you the ability to edit and save the output. 
  11. Hover icons on ref labels to view PR numbers and titles. Right-click the label for options to open them on GitHub.com.
Categories: Companies

Deprecating TestTrack integration

TargetProcess - Edge of Chaos Blog - Wed, 05/17/2017 - 15:37

Did you know we have an integration with TestTrack? Probably not. It's a legacy plugin – a really old one – from Targetprocess 2 that connects to the TestTrack bug tracking tool and periodically synchronizes defects from TestTrack with bugs in Targetprocess. Even the research we did in 2008 indicated that it was the least used plugin of all, but now its usage is even lower since it's only available for On-Premises installations (we removed it from On-Demand accounts about 6 years ago).

We haven't added much functionality to the plugin over the last decade, but we still had to keep it as part of the code base (which we're working on reducing), maintain automatic tests, and so on.

It's very possible that this will not affect anyone reading this post, but it's still a formal part of the software and needs a special announcement. So yes, starting with Targetprocess v.3.11.4, integration with TestTrack will no longer exist. 

This the part where I'm supposed to say something nice, maybe even dramatic about this feature... but I can't really think of anything. Sorry. Anyway, our code will be a little bit lighter and developers will be a little bit happier, so that's good news, even if it's minor.

Categories: Companies

Visual Reports: Formulas Editor Change

TargetProcess - Edge of Chaos Blog - Tue, 05/16/2017 - 15:20
Invalid formulas and old-style report formulas will not be saved

We have disabled the ability to save invalid and previous version graphical report formulas .

formula

You can use special functions if you need to create reports using the formulas from previous version of graphical reports.

  1. RAW_TEXT(<Targetprocess DSL text expression>) for text or boolean formulas. For example:
    RAW_TEXT("Test")
  2. RAW_NUMBER(<Targetprocess numeric expression>) for numeric formulas. For example:
    RAW_NUMBER(Int32.Parse("45"))
  3. RAW_DATE(<Targetprocess date expression>) for using text or boolean formulas. For example:
    RAW_DATE(DateTime.Parse("3 September"))
  4. RAW_ARRAY_TEXT(<Targetprocess text array expression>) for using text or boolean formulas. For example:
    RAW_ARRAY_TEXT(AssignedEfforts.Select(Assignable.Name))

     

We will really appreciate your feedback on our reports editor. What do you like about it? What could be improved? Let us know what you think at ux@targetprocess.com

Categories: Companies

Service Desk updates: Color Themes and Request Type improvements

TargetProcess - Edge of Chaos Blog - Tue, 05/16/2017 - 09:39

It's been awhile since we posted about our progress on Service Desk. We have just released several nice features that we'd like to share with you.

Color themes

You can now change the look of your Service Desk by picking from one of the predefined color options. This is the first step to making the colors fully customizable and allowing you to use your company colors in addition to your logo.

sd_color_schema

If you'd like to customize something other than color, please share the details with us. This will help us make sure we don't miss anything important, while hopefully not over-complicating everything under the hood.

Disabling votes

Previously, the "Vote" button was available for any request type, which did not always make sense. You don't typically need someone to upvote your browser crashing issue or something like that, right? So you can now define which request types will have the Vote button, and which will have it removed.

You can configure voting at Targetprocess Settings -> Request Types.

request_type_options

Default visibility

We've received a fair amount of feedback along the lines of "why can't I make all requests public" or "the new request type is always private". Since you can already create your own request types, we decided to make it more flexible. When submitting a new request, the "Private" check-box will either be checked or not, depending on what you select at Settings. Users, however, will still be able to change the visibility (depending on the particular request).

You can configure default visibility at Targetprocess Settings -> Request Types.

default-visibiliy

Fixed bugs

We also fixed a number of bugs and made some internal changes. Among the most noticeable are:

  • State grouping: states before the 'Planned' state are no longer added to the 'In Progress' group.
  • Fixed half a dozen IE-specific bugs (or should we say, we made Service Desk more compliant with the bugs of Internet Explorer?).
  • Fixed the order of custom fields at the Add Request page. It is now updated automatically when you reorder them in Targetprocess.
Please note that the changes above require Targetprocess version 3.11.2. If you are hosting Service Desk locally using IIS, you will also need to update .Net Core to 1.1. See our guide for more info.
Categories: Companies

Why Shu Ha Ri and Scrum Can Make for a Dangerous Combination

NetObjectives - Mon, 05/15/2017 - 21:43
Note: This blog assumes the reader understands the basic roles and practices of Scrum. Scrum suggests that the way to improve a team’s workflow and the organization within which it works is to remove impediments to its core roles (product owner, team, scrummaster) and practices (cross-functional teams, daily standups, and using time-boxing for work, demos and building backlogs). It takes an...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

Visual Project Management: Past and Future

TargetProcess - Edge of Chaos Blog - Tue, 05/09/2017 - 17:33

No matter what kind of project you’re managing, there’s a direct, causal relationship between process and outcome. In other words, it’s not just what you’re working on that matters but how you work on it.

Traditionally, the project management discipline has prized control and long-term forecasting over the particulars of work in progress. But considering 46 percent of all projects still fail to meet their original goals and intent, there’s a growing demand for real-time visibility into the movement of tasks and resources.

Visual project management is a new approach (and new technology) designed to address some of these challenges. By embracing it, teams and organizations can complete projects of any type with greater speed and efficiency.  

What is Visual Project Management?

For the most part, visual PM is exactly what it sounds like: a project management strategy designed to increase success through visualization of project components, such as data and tasks.  Mark Woeppel, the author of Visual Project Management, describes it like this:

“Visual Project Management is a process that uses visualization of the delivery process to drive team behaviors.”

Visual features can be a valuable asset for any project style, but they’re most commonly associated with agile methods such as Scrum and Kanban. In some ways, visual PM takes its cue from the good old-fashioned whiteboard. The whiteboard has served as a roadmap, progress tracker, and collaboration tool for all kinds of development teams.

But the history of visual PM is much older than the whiteboard.

The oldest roots date back to 1896, when Polish economist Karol Adamiecki created the “harmonogram” — a floating bar chart used to show tasks or resources changing across time. Not long after, in 1912, the famous Gantt Chart was born — used first to build ships during WWI and later to construct the Hoover Dam.

Adamiecki’s “harmonogram.” aom.org

Adamiecki’s “harmonogram.” aom.org

Michael Dubakov, Founder and CEO of Targetprocess, says that visual PM started to crystalize around 2010 with the popularity of the Kanban approach. “One of the Kanban principles is to visualize workflow in order to better understand what is going on and what can be improved.”

Modern visual project management software is much more advanced, but its purpose is the same: to provide greater flexibility and improved outcomes through visibility into bottlenecks, tasks interdependencies, progress, and priorities. “In the recent 5 years we have seen a spread of visual tools like Kanban boards, timelines, and integrated BI systems with powerful reporting,” says Dubakov. In all kinds of industries (especially the IT world)  visual project management is now helping teams stay in sync and respond to changing requirements.

In terms of actual methodology, many of the visual tools that have proven useful combine the best aspects of Kanban and lean production with the Scrum foundation that dev teams are used to. Some users have taken to calling this style “Scrum-ban.”

Common visual features include:

  • Real-time dashboards
  • Timelines
  • Graphic reports (Gantt, burndown, etc.)
  • Boards (Kanban)
  • Product Roadmaps
The Changing Landscape

When fully embraced, visual project management can bring some dramatic improvements to the way teams collaborate and work. As modern software continues to evolve, more teams will adopt visual tools to improve their development lifecycles, over time raising the benchmark for an efficient project delivery process.  

Let’s take a look at some of the specific ways visual tools can impact the future of project management. As your organization plans products and strategies for this  year, try to pull some of these ideas into the conversation.

The Ability to Isolate Problem Areas Faster

As your teams work through various projects, there will inevitably be obstacles — things that slow the movement of tasks, stories, or feature requests during a sprint. Without the necessary visibility, it’s difficult for a project manager to troubleshoot delays or recurring problems.

A visual project management solution can make spotting and solving these “blockers” much easier.  You get a real-time picture of where each component of a project rests, so you can quickly identify bottlenecks and trace issues to their source. For example, let’s say you notice that user stories are repeatedly getting “stuck” in the testing phase or re-entering a later sprint due to unsatisfactory completion. By visualizing the workflow, you can isolate the root cause and then communicate with the relevant team members to initiate change.

Better Resource Planning and Allocation

Resource and requirements planning is one of the most crucial components of any project: get it wrong, and you’ll have a project that gets delivered both late and over budget. There’s a little more leeway with agile projects (since work is done in short iterations), but decision-makers still need to stay responsive to changing requirements and be able to shift priorities or reassign team members when necessary.

Feature Planning By Teams

The speed of change  demands fast resource management. The right visual tools can help you tighten your development lifecycle by maximizing your use of resources—both in the planning phase and in continued optimization during the project. A visual resource planning feature, for example, shows where your team members are assigned and what tasks they’re working on. You can also drill down to assess individual skill sets and schedule availability.

More Projects Completed On-Time

One of the first principles of the Agile Manifesto is “. . . early and continuous delivery.” If your goals are built around this principle, it’s important to remove every possible impediment and give developers maximum visibility. Without the right tools, project information gets siloed into email threads, chat conversations, and spreadsheets, and team members have a hard time remembering who’s working on what. Ultimately, this leads to redundant efforts and a longer cycle time.  

Visual PM can speed progress by conveying real-time project information in a way that is easier to access, understand, and share. It also makes it easier for team leaders to track work in progress and remove impediments before they delay the product. A Kanban board — which uses “cards” to move tasks through different stages of the project — is a perfect example of visual workflow optimization.

Personal Kanban Board

The Spread of Project Management Solutions

Finally, the growing popularity of visual features means that project management software itself will become easier to implement and easier to use for all team members. Even smaller companies with limited experience can set up a cloud-based visual PM solution in less than a day. That means small, agile teams can become even more agile without the overhead of a consulting service or an expensive, time-consuming implementation.

With agility at a maximum, project teams can improve the customer experience by running faster iterations with fewer bugs. Thus, visual PM tools create a more sustainable, scalable development model.

There is, of course, room to grow. Dubakov points to a general lack of research in the visual PM field. “To my knowledge, there are no people who understand both domains well enough in order to lead the visual management movement,” he says. In the coming years, we can hope to see additional research and innovation in some of the following areas:

  • Using visual PM tools to aid decision-making
  • Different visual approaches for different sub-domains
  • Visualizations for planning, capacity management, tracking, and forecasting
  • Process management and problem resolution
  • Closer integration between visual PM and business intelligence tools

*

Visual project management isn’t some radical new approach that turns the discipline upside down. It’s just a set of tools and techniques that reinforce what we already know: people work and manage projects more efficiently when they’re “in the loop,” and when they have a clear picture of how project components move and interconnect.  The best way to represent and share this information in real time is not with a list, or a spreadsheet, or a series of emails, but with a visual.  

Aleks Peterson is the content manager at TechnologyAdvice, a B2B research firm that connects buyers and sellers of business technology.

Categories: Companies

Test-First for Quality

NetObjectives - Sun, 05/07/2017 - 22:18
Quality is a pretty open ended term.  Test-first is often thought of as implementation and verification – is the code being written of high quality?.  But there is also quality to the customer – is the right thing being built?   There is also the quality of the culture of the organization developing the software – is collaboration present?  And finally, the quality of the process being used – is...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

Getting Business Into The Agile Mindset

NetObjectives - Sun, 05/07/2017 - 09:37
I was recently asked “Any recommendations on a book for how a middle manager can drag a business into an Agile mind set against their will?”  The answer is – “you can’t drag business into an Agile mind set against their will.”  In fact, you really can’t drag anyone into an Agile mindset against their will.  I also find it ironic that I hear Agile coaches ask me a similar question, “Any...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

GitKraken.com Now 100x Artsier

About SCRUM - Hamid Shojaee Axosoft - Wed, 05/03/2017 - 18:09

What do you get when you cross a traveling salesman with a Kraken? Art. You get art.

GitKraken v2.5 is now 3x faster than SourceTree, and gitkraken.com is 100x artsier. We’ve combined our love for art and technology and launched a brand new version of our website. Turns out we have a lot of digital artists at Axosoft! One of which is Kyle Smith, a GitKraken developer, a master at digital mark-making, and our first featured artist on the website.

GitKraken v2.5 Featured Artwork

Kyle has been an artist since he started doodling in high school. “My default doodle was a single squiggly line that tightly curved around itself, which from a distance just looked like one large shape,” said Kyle.

He reminisces, “When I began programming, I loved the idea of one day reproducing my high school doodles with code.” So, he started to learn about computer generated art in college, and after graduation, Kyle stumbled upon a paper that described exactly what he wanted to do: turn an image into points on a grid (in a way that resembles stipple art), then connect them using a solution to the traveling salesman problem. He implemented the process in JavaScript and created an SVG, which when animated with vivus, made the image appear to be drawn.

*Knock Knock* Enter Traveling Salesman

The traveling salesman problem (TSP) is a well-known problem in which one must find the shortest route between a set of cities, where each city is visited once and only once. “The great thing about an optimal solution to a 2D traveling salesman problem is that the lines are proven to never cross. So, like my early doodles, this gives images the effect of lines tightly curving around themselves,” said Kyle.

However, rather than creating a single path, as the paper describes, he split the image into many paths. Now, when the svg is animated with vivus, multiple paths are drawn at once, creating a more visually interesting animation.
v2.5 featured artwork
Like I said, we have a lot of digital artists at Axosoft, and it got us thinking that we probably have a lot more in our community too. So, we invite you to create a GitKraken-inspired digital art piece that could be featured on GitKraken.com. Check out our submission guidelines, and get to it!

Categories: Companies

GitKraken v2.5

About SCRUM - Hamid Shojaee Axosoft - Wed, 05/03/2017 - 17:26

While working on improvements for GitKraken v2.4, we noticed that GitKraken was not running as efficiently as we would like, especially on Windows. As many Windows Git client users may know, most Git GUIs run at the speed of a tortoise, while GitKraken runs its race as the hare.

Sadly, we all know how this story goes… Similar to the hare, GitKraken would blaze ahead when performing certain actions and take its time when performing other actions. So, we decided to give GitKraken a bit of a jolt to see what would happen!

the flash

GitKraken’s new found power of super speed kicked in, and the performance improvements were immediately noticeable when checking out a branch:

branch checkout v2.5

That jolt really got GitKraken going—it will no longer take a nap when you request to view the history of a file:

file history v2.5

While experimenting, and benchmarking the improvements GitKraken had made, we noticed that another Mac and Windows Git client (that is most definitely not SourceTree) had made “significant” improvements to its Windows platform. While they were impressed with their results, we really only had one thing to say:

the Flash

For a bit of fun, we decided to benchmark their improvements against our own. And hey, the more the merrier, right? So, we threw the CLI in there too:

windows checkout speeds

That’s right, GitKraken v2.5 is nearly 3 times faster than SourceTree v2.0! And if you’re wondering ‘how can GitKraken be faster than the CLI?!’ The answer is: because GitKraken does not rely on Git tools and because it does all Git operations directly, speeds can be increased through multi-threading and other techniques. Game, set, match!

Be sure to check out our release notes to see the rest of the improvements and bug fixes in v2.5. 

Categories: Companies

Open Allocation Experiment

TargetProcess - Edge of Chaos Blog - Wed, 05/03/2017 - 16:45

In June 2016, we switched most of the people inside our company to open allocation. They have the freedom to start their own initiatives that are aligned with the central goal of providing a better user experience and fixing critical problems in Targetprocess product.

10 months have passed, and we can now analyze the experiment results. In this post I'll share my opinion about the experiment and mix it with the opinions of the people who participated.

Deadlines

Here is the current initiatives Roadmap. A very good thing is that almost all initiatives were implemented on time. It means people respected their commitments and did their best to keep promises. A bad thing is that some of the implemented features were still not deployed to production servers due to huge infrastructure changes caused by the microservices approach. Basically, you can't give a promise to release something when the infrastructure is not ready.

initiatives_open_allocation

Another trivial observation is a struggle to fit R&D activities into the Initiatives model. If a team doesn't know how to attack the problem, it created "Research initiative", thus we timebox research. Then, when a solution is found, the team starts a usual Initiative with the results.

Overall, we wanted to solve the problem of speedy delivery, and we got mixed results. Yes, most features were implemented on time, but the infrastructure held them back.

Small Lesson #1. People don't like deadlines, but... deadlines work (when you have no problems with infrastructure).

Deadlines lead to cut corners, worse quality, and poorer solutions. In my personal opinion, this is not a huge problem, since you always have to balance quality and time. Estimates are not forced and, overall, teams have enough time to complete features with good quality.

Freedom of choice

Freedom boosted motivation. People were more enthusiastic to fix some old problems and work on things they wanted to improve a long time ago. Here are some feedback quotes:

#1

On its own, the idea is great and summarizes the essence of any modern social science since it gives freedom to choose your work, stimulates an individual's initiative, pro-activity and creative potential

#2

It inspires people to take ownership of our product. A good practice for freedom, responsibility, and trust.

#3

People feel more passionate and responsible about what they build, I guess. We finally have kind of deadlines, that we stick to. We have a clear definition of done for features, with clear deliverables such as product demo, blog post, working piece of software etc. It seems we deliver better quality, faster and more often.

Focus

Initiatives force you to focus on a single task. It improves timely delivery, but hurts mutual help. You might think twice to dedicate several hours of your time to help someone from another team. Sometimes it is good, but sometimes it can lead to local optimization. Sure, you will have your feature delivered on time, but from a company level your help may be extremely valuable.

I think this trade-off is OK. If you like to help other people, you can act in the Free Agent role rather than join an initiative. Or, you become more creative and try to teach people quickly instead of doing everything yourself.

Company alignment

This got worse. Ideas are quite diverse and I hoped to have an emergent vision as a result. I don't think it happened though. We indeed fixed several important problems, but some of the top problems are still there, like extremely poor notifications. I defined a wide goal to improve UX and increase NPS, but this goal was too broad and almost all features can be stretched to fit this goal. In my opinion, this lead to a slight feeling that our direction is unknown and the product has no vision.

Small Lesson #2: Define a bold goal for the year and quite narrow goals for the quarters.

And a quote:

The scope we do is driven by someone's desire but not by market demand. Sure, there is a filter which guarantees that useless feature won't pass. But this filter doesn't guarantee that necessary feature will go into development (because nobody would like to take them and HEADs cannot force). Important items can be in a backlog for years.

Initiative Reward

One of the worst decisions we've made is a reward for successful Initiative completion. Teams that complete an Initiative got several Orange Days (which can be converted to Days Off). This immediately downplays the contribution of all people outside Initiatives.

#1

Initiatives violate our core value: trust. A company should trust that their people will do their best to get a job done. Initiatives might give off the impression that "we don't trust you will do great work without a reward, so we give you a bonus that will stimulate you to complete work on time". It is assumed that development speed is low due to lack of deadlines, but in reality, complexity of integration and some external blockers are the cause.

#2

Some one still needs to do the "dirty jobs" and I don't think that it's fair that this work is not rewarded with orange time.

We wanted to stimulate the Initiatives practice with an additional reward, but it was a bad idea. In fact, freedom of choice and regular intrinsic motivation is enough to make great things.

Small Lesson #3: Don't underestimate intrinsic motivation.

Lack of Training

Another mistake we've made is poor guidance. Yes, I wrote about the practice, ran clarification sessions, and answered questions. But after this initial kickstart, I did a poor job of supporting and promoting it.

I should have worked with key people and ran educational session about how to define top problems, how to do UX, how to test results, etc. Self-organization requires good skills and great understanding of the business context. I relied on cheap self-organization, but this doesn't work in the complex environment of a B2B SaaS company.

Huge lesson #4: Adaptive self-organization demands high energy costs.

Overview

In general, people liked the idea, but implementation was far from perfect. Can this model replace traditional Product Managers and Product Owners? Yes, it can. However, make sure that you do the following to avoid our mistakes:

  1. 20% of people should be highly experienced, have deep understanding of business context and good understanding of product development practices. If you don't have it, run training programs and maybe in a year people will be ready.
  2. Education should not stop.
  3. Information transparency is extremely important. You should have a process to collect requests from customers using various channels, aggregate their feedback and help people to distill top problems to focus on.
  4. Be careful with bonuses and rewards. By default it is easier to not have them at all.
  5. Implement freedom gradually.

#5 demands clarification. Imagine, you have a completely strict process where people got all assignments from managers. Here is an example of gradual freedom:

Choose own tasks from a story > Choose own stories from a backlog > Choose large features from backlog > Participate in backlog creation > Choose anything you believe is right.

If you jump to complete freedom from the typical Scrum practice of "Choose own stories from a backlog", people will feel frustration. Help them one step at a time.

Will we stick to Initiatives model?

I think we will go one step back and let people choose features from a backlog and participate in backlog creation, running required training programs for product development in parallel. With more experience we will restart the Initiatives practice. It is fun and works quite nice, but we were unprepared for it as a company, and I was unprepared for it as a leader.

Categories: Companies

Targetprocess v.3.11.2: Undelete Projects and Users

TargetProcess - Edge of Chaos Blog - Tue, 05/02/2017 - 07:59
Restore deleted projects or users

You can now easily "undelete" Projects and Users from the "Deleted items" menu in Settings. Previously, it was not possible to restore deleted Projects and Users without using the API.

55lezba4li

Please find more info in the guide.

Visual Reports Improved

We recently made some nice improvements to the Visual Reports Editor. Read about them at this dedicated blogpost.

We really appreciate your feedback on our reports editor. What do you like about it? What could be improved? Let us know what you think at ux@targetprocess.com

Fixed Bugs
  • Fixed incorrect effort calculation in Burn Down charts when a Feature is removed
  • Added support for decimal values in custom fields on the Timesheet
  • Fixed: Contributors could not create Releases for Projects that they were not a member of
  • Fixed an exception that would occur when Test Plans and Test Cases on the same Board had different tags
  • Deleted Users will now have a strikeout through their name if someone tries to @mention them in comments
  • Processes are now sorted alphabetically in the Quick Add menu
  • Fixed an exception ('Oops...Something's wrong') that would occur when adding an 'Effort' custom unit to cards in a Person/State view
  • Fixed an inability to delete a Process that is used by deleted Projects
Categories: Companies

Some Laws of Software Development

NetObjectives - Sun, 04/30/2017 - 13:28
This blog continues my series on Going Beyond Practices to Achieve Objectives.  There is a significant difference between a law and a principle.  In Values, Practices and Principles Are Not Enough we defined them as: Principle – a fundamental truth or proposition that serves as the foundation for a system of belief or behavior or for a chain of reasoning Law – (natural laws) a statement of fact,...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

An Introduction to Functors

About SCRUM - Hamid Shojaee Axosoft - Tue, 04/25/2017 - 18:18
Introduction

In a previous article, we talked about Semigroups and Monoids, which are abstractions that let us combine values of the same type together. In this post, we’ll take a look at Functors, which allow us to operate on values inside containers without having to know any of the implementation details of the containers themselves.

NOTE: This article is based on an Axosoft Dev Talk titled Practical Category Theory: Functors. Watch that video or keep reading!

Before we embark on our journey, we should probably take a quick trip through higher-kinded types!

Higher-Kinded Types

When we program in a language like C# or Java, we often run into “concrete” types like int, string, and bool. The neat thing about concrete types is that we always know all the operations that we can perform on them (ints can be added, bools can be negated, and so on).

One step up on the abstraction ladder are “generic” types, like List<T>. A fancy term for generic types is “parametric polymorphism:” “parametric” because we’re working with a type parameter, and “polymorphism” because the parameter in question can have multiple (“poly-“) shapes (“-morphism”). So, we know what operations we can perform on the List itself (iterate over all its elements, Add an item, etc.), but we know absolutely nothing about the type represented by T. This gives us a lot more power of abstraction because we can write methods that manipulate these generic structures and have them guarantee to work no matter what type we eventually fill in for the type parameter.

In Haskell and Purescript, we’d write List<T> as List t: the name of the generic type (List) comes first, and the name of the type parameter (t) comes next, separated by a space. Haskell and Purescript know that t isn’t the name of a concrete type (like if we had written Int or String) because it starts with a lowercase letter.

We can go one step further and write a type like IEnumerable<T>, where our container type isn’t a concrete type but is only an interface. Now, we know only a little bit about the container type itself (specifically, that it has elements over which we can iterate), and we still know nothing about T. The number of operations we can perform on a value of type IEnumerable<T> is even smaller than those for List<T>. This limitation is actually a good thing because now we can pass in a Stack or a Queue to a method that takes an IEnumerable, for example, and the method will work as expected.

Usually, this is where we would have to stop because most languages don’t let us go any more abstract. However, Haskell and Purescript don’t have this restriction and support so-called “higher-kinded” types, where we can make both the internal type and the container type fully generic. If C# had syntactical support for this, it might look something like T1<T2>. T1 could be IEnumerable, Queue, etc., while T2 could be int, string, etc. Haskell and Purescript, however, do support this concept of higher-kinded types and use this syntax: f t (where f is the container type and t is the type parameter). Because f is lowercase, we know that it’s generic as well as t, and so can be any type that requires exactly one type parameter. For example, the following types would fulfill f:

  • List, which holds zero or more values of the same type.
  • Queue, which also holds zero or more values of the same type, but doesn’t allow random access.
  • Maybe (A.K.A. Option or Optional), which can contain either one value or be empty.
  • Promise, which eventually produces a value.
  • A Redux store, which we can think of being parameterized by the type of the state it contains.

Whereas the following cannot be used for f:

  • Map, because that requires two type parameters, one for the key and one for the value.
  • string, because that doesn’t have any type parameters (another way of saying that is that the type string is already fully concrete).
  • Tuple, because that also requires two or more type parameters (depending on the number of elements it contains).
  • A Redux reducer, which requires two type parameters, one for the message and one for the state.
Fun Fact!

In Haskell or Purescript, the higher-kinded type parameter (f in f t) is usually named f or m, while the type parameter it takes (t in f t) is usually named a (or b or c if more than one is needed).

Constraints

Granted, we really can’t do very much with a value of type f t because we intentionally don’t know very much at all about it. However, we can put constraints on our type parameters. In C#:

class Foo<T> where T : SomeConstraint

Now, T can’t be just anything but instead has some restrictions on what can be plugged in for it. After we’ve put one or more constraints on T, we now know more about what we can do with it. For example, if T is constrained to be an instance of IComparable, that means Foo will only accept types that support the CompareTo method, like int or char (but not, say, List<string>). In Haskell or Purescript, this type can be written SomeConstraint t => Foo t, which means that type t must support the operations in SomeConstraint.

In Haskell and Purescript, we can also place constraints on our higher-kinded type parameters, like so: SomeConstraint f => f t. Now, we know that f supports whatever operations are included in SomeConstraint, and we can plug in any type that supports them. This is approximately analogous to the idea behind IEnumerable<T>, where the container type is abstract and so we can choose a specific type, like List or Queue, to make the type concrete. (We might write that example in Haskell and Purescript as IEnumerable f => f t.) We can also use more than one constraint on a single parameter or place constraints on more than one parameter at a time, like so:

(SomeConstraint f, SomeOtherConstraint f, AnotherConstraint t, YetAnotherConstraint t) => f t
Recap

What all this allows us to do is to have a system of specifying the structures of values, which will come in handy when we get to Functors below. Higher-kinded types allow us to focus on values that have general structure, and we can narrow the possibilities down with constraints.

Phew, that’s a lot to digest. Here’s a summary of how the different concepts (roughly) translate between C# and Haskell and Purescript.

Concrete Types

We know everything there is to know about these types.

C#
int
Haskell, Purescript
Int
Generic Types

We know everything there is to know about part of these types.

C#
Foo<T>
Haskell, Purescript
Foo t
Constraints

We know some things about various parts of these types.

C#
// Constraint on the "traditional" type parameter
Foo<T> where T : IBar
// Constraint on the container type itself
// Approximately:
IFoo<T>
Haskell, Purescript
-- Constraint on the "traditional" type parameter
IBar t => Foo t
-- Constraint on the container type
IFoo f => f t
Higher-Kinded Types

We only know about the very general shape of these types, but we can place constraints on them in order to do useful things with them.

C#
// Doesn't exist, but might look something like:
T1<T2>
Haskell, Purescript
f t
Functors

Lo and behold, we’ve made it to Functors!

We’ve been making statements about the “structures” of types without a clear definition, so here goes:

Structure

Rules about how you can use a type (i.e. the operations that can be performed on it). In an object-oriented (OO) language, this might be represented by interfaces; in a functional language, this might be represented by modules or typeclasses.

IEnumerable<T>, for example, has a different structure from IComparable<T>, because IEnumerables can be iterated over, sorted, etc., while IComparables can be compared.

Functor is a specific structure that supports exactly one operation: map. map allows us to operate on value(s) inside a Functor (which we can think of as a container of some sort) without knowing (or caring) how the Functor is implemented. Each Functor has its own rules for how map works, but this general theme of manipulating contained values is the same.

You’ve already used map if you’ve ever used Array.prototype.map in JavaScript or LINQ’s IEnumerable.Select in C#, for example. You didn’t have to know how the container (the Array or specific IEnumerable) was implemented, since its implementation of map took care of that for you. All you needed to do was provide a function that takes an element of the list and returns something else, and the container handled the rest.

Without further ado, let’s take a look at map‘s type signature!

C#
public interface IFunctor {
    // There's no second parameter, because this method is on the `IFunctor` we want to map over
    IFunctor<TResult> Map<TResult>(Func<T, TResult> fn);
}
Haskell, Purescript
-- Here, we explicitly write the Functor to map over as the second parameter, because Haskell is functional rather than object-oriented
map :: Functor f => (a -> b) -> f a -> f b

map takes a function and a Functor and returns the Functor after the function has been applied to its element(s). The type of the element(s) inside the Functor is allowed to change.

So, Functors are really, really simple. Their only special “skill” is that they allow you to apply a function to what’s inside them.

What Can (and Can’t) Be a Functor?

So far, we’ve only seen List‘s implementation of Functor, but what else could be a Functor?

Queue can, because it can allow a function to be applied to all its elements. Maybe can also be a Functor: if there is no value, then an empty Maybe is returned; otherwise, a Maybe with its value modified by the provided function is returned. Promise can implement map by allowing you to modify the value that the Promise will eventually resolve to (e.g. somePromise.then(x => x + 1)).

So what can’t be a Functor? Well, a Redux store probably can’t. While it certainly allows its state to be modified, being a Functor would mean that the type of the state could change, since any function we use with map with must be allowed to change the type of the elements inside the Functor. We usually don’t want the type of our Redux state to change over time, so a Redux store isn’t a valid Functor.

Let’s see some quick examples of Functors in use. Here’s what it looks like to map over a list in JavaScript, C#, and Haskell and Purescript:

JavaScript
[1, 2, 3].map(x => x.toString()) // ["1", "2", "3"]
C#
new[] { 1, 2, 3 }.Select(x => x.ToString()).ToList() // new[] { "1", "2", "3" }
Haskell, Purescript
map show [1, 2, 3] -- ["1", "2", "3"]

Note that in the above example, the List started out as a List<int> but was converted to a List<string>. This is another important property of map that we’ll get to below.

And here’s what it looks like to map over JavaScript’s Promise type instead:

JavaScript
Promise.resolve(1)
// Think of `then` as `map`
.then(x => x.toString()) // resolves to "2"

In both cases, we’re handing map a function and each Functor is doing the rest for us in its own specific way.

As we can see, the concept of a Functor is intentionally very general, and this idea of very general abstractions is what makes category theory so powerful.

Example

To summarize: Functors allow us to treat “what to do” and “how to do it” as separate concerns. After a map implementation is written for a type, it can be used the same way with any function (as long as its parameters are the correct types, of course).

Now for a real-world example! Let’s pretend that we have a Maybe type of some sort in JavaScript, along with a corresponding fromMaybe function that takes a modifying function, a default value, and the Maybe to map over. If the Maybe contains a value, fromMaybe will return a modified version of that value; if, however, the Maybe does not contain a value, fromMaybe will return the default value that it was passed.

As an example, we might traditionally work with possibly nonexistent values like so:

const result = thingThatMightFail();
return result.value
    ? result.value + otherValue
    : 0;

The issue with this approach, however, is that we can forget to check that result is null or undefined (‘cannot read property of undefined,’ anyone?). If, however, we use some sort of Maybe object, we might be able to rewrite the above using fromMaybe as follows:

const result = thingThatReturnsAMaybe();
return fromMaybe(
    v => v + otherValue, // Function to apply if we have a value
    0, // Default value
    result // Maybe object
);

Now, if we forget to use fromMaybe on our result, we’ll catch it when we try to actually use this value. Granted, this isn’t as useful in JavaScript as it is in a statically-typed language like C# where we’d be able to catch such errors at compile-time, but using Maybe like this everywhere we’d use null or undefined still allows us to reason about our code and know what can return a value that might not exist (instead of just hoping that we remembered to check for null or undefined everywhere we use a potentially nonexistent value).

If we want to run multiple operations in sequence on a value that might not exist, we might think to do it like this:

const json = someAjaxRequest();

let result = defaultUser;
if (json) {
    const id = extractId(json);
    const user = getUserById(id);
    result = upgradeUser(user);
}

However, with Maybe, we can write it differently:

Note: R.pipe is a function from the Ramda.js library that “composes” functions: it takes several functions and chains them together to create a new function (for more details, see the docs).

Also, for clarity, psuedo Flow function type annotations are included.

const maybeJson: Maybe<JSON> = someAjaxRequest(); // someAjaxRequest: () => Maybe<JSON>

const result: User = R.pipe(
    (maybeJson: Maybe<JSON>) => map((extractId: (JSON) => Id), maybeJson),
    (maybeId:   Maybe<Id>)   => map((getUserById: (Id) => User), id),
    (maybeUser: Maybe<User>) => fromMaybe(
        (upgradeUser: (User) => User),
        (defaultUser: User),
        maybeUser
    )
)(maybeJson);

And here’s the same example, but this time we’ll remove unnecessary Flow type annotations and take advantage of a technique called currying in order to see what the same code might look like in a real-world situation:

const maybeJson: Maybe<JSON> = someAjaxRequest();

const result: User = R.pipe(
    map(extractId),
    map(getUserById),
    fromMaybe(upgradeUser, defaultUser)
)(maybeJson);

So, let’s see what we gain from using Functors. As opposed to in the first, ‘traditional’ example, we didn’t have to manually handle the case where no value was returned. The Maybe Functor itself was able to decide how to do so, and all we needed to worry about was giving map the functions that we’d like to perform if a value does happen to exist. We can use any functions we want for each step in the pipeline, as long as they have the correct types (namely, the return type of each one must be the type of the next one’s parameter).

Functors are incredibly common in practice, and a good rule-of-thumb is to ask yourself whenever you begin to write a function that operates on a data structure if the function could be made general enough to operate on a Functor instead. For example, Haskell/Purescript functions like replace and zip could be defined to work with lists specifically, but they’re instead implemented to only require that their parameters are Functors; as such, they work on many different structures for free! They don’t need to know anything about how each of those Functors works on the inside because map handles the details for them.

Laws

Finally, Functors have two associated “laws” to ensure that the Functor will behave as one would expect. Don’t worry, you won’t go to jail if you get these laws wrong (although it is certainly an unpleasant surprise when a Functor is “unlawful”).

Law #1: Identity

Mapping the identity function over a Functor has no effect.

Fancy pseudo-Haskell way to say it:

map id = id

This one’s pretty self-explanatory: if your function doesn’t actually do anything to the element(s) inside the Functor, then it would certainly be surprising if you got back a different result than what you passed in.

JavaScript Example
map(x => x, [1, 2, 3]) // [1, 2, 3]
Law 2: Composition

Multiple maps in a row can be composed into one without any changes in the overall behavior.

Fancy pseudo-Haskell way to say it ((.) is the function composition operator):

map f . map g = map (f . g)
JavaScript Example

We could write our earlier JSON-manipulation example like so if we combine the two-in-a-row maps into a single map, with the new function to use being the composition of the two steps in our pipeline.

R.pipe(map(extractId), map(getUserById))(json) // map(R.pipe(extractId, getUserById), json)
Go forth and map!

And that’s it for Functors! They’re very simple structures that give us a lot of power. Just like Semigroups and Monoids, they’re used very commonly because they’re so simple to reason about. And, because they’re so general they allow us to write functions once and use them on all sorts of different data structures, guaranteed!

Categories: Companies

The Objective of Time-Boxing

NetObjectives - Sun, 04/23/2017 - 14:22
This blog continues my series on Going Beyond Practices to Achieve Objectives. A webinar on Blending Kanban and Scrum is also available.   Timeboxing is used as a project planning technique. The schedule is divided into a number of separate time periods (timeboxes), with each part having its own deliverables, deadline and budget. In Agile, these time boxes are known as “iterations” (XP and...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

Values, Practices and Principles Are Not Enough

NetObjectives - Sun, 04/23/2017 - 14:12
This blog continues my series on Going Beyond Practices to Achieve Objectives. A webinar on Blending Kanban and Scrum is also available. Agile has been around for over 2 decades now. Most every method talks about values, principles and practices. The Agile Manifesto, for example, is comprised of 4 values and 12 principles. XP, Scrum, Kanban, SAFe, LeSS and Nexus have added a considerable number...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies